Re: priority bug

2007/8/31, sergio <ejabberd <at> sergio.spb.ru>:
> ejabberd allows to set priority outsite char (-128..128) range

Bug and patch submitted to:
https://support.process-one.net/browse/EJAB-348

That patch puts priority = 127 if the user tries to put a very high value.
And puts -128 if the user tries to put a very low value.

Do you see this correct, or should be better to put priority=0 if the
user exceeds the allowed range?

Re: priority bug

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Re: priority bug

2007/8/31, sergio <ejabberd <at> sergio.spb.ru>:
> ejabberd allows to set priority outsite char (-128..128) range

Mickaël Rémond said in the bug tracker:
> This is not a bug but a feature.
>
> I do not see any good reason to enforce this limitation.
> It was intentionally left open ended.
> Some people are using timestamps for example to make sure that their last resource > is the one that has the
highest priority.
>
> I am ready to hear explaination of what harm this feature could cause.

I bring the discussion from the bug tracker to the mailing list again,
so everybody can participate.

I guess the opinion of  the author of the protocol in question may be
helpful. I'll ping Peter Saint-Andre next monday.

Anyway, I see two solutions:

a) Mark the bug as INVALID or WON'T-FIX and reject the patch. If so, I
strongly recommend to create a new document that describes what
inconsistencies are in ejabberd's implementation of protocols. Publish
it, and add to it any other bug-turns-feature [1]. This way other
Jabber developers will not be surprised of some particular behaviors
in ejabberd which are not compliant with standard protocols. This will
also prevent the bug tracker from being filled with many INVALID bugs.

b) Apply the patch, mark the bug as SOLVED, and also implement a new
option to disable this limitation.

[1] Another protocol incompliance that can be considered a feature is
tracked here:
'Lock created room until configured, unless it's non-MUC or instant'
https://support.process-one.net/browse/EJAB-341

Re: priority bug

Badlop wrote:
> 2007/8/31, sergio <ejabberd <at> sergio.spb.ru>:
>> ejabberd allows to set priority outsite char (-128..128) range
> 
> Bug and patch submitted to:
> https://support.process-one.net/browse/EJAB-348
> 
> That patch puts priority = 127 if the user tries to put a very high value.
> And puts -128 if the user tries to put a very low value.
> 
> Do you see this correct, or should be better to put priority=0 if the
> user exceeds the allowed range?

imho it's better to reject such priority requests with error..

--
sergio.

Re: ejabberd newbee no web admin and can't regiter

ejabberd.log

=INFO REPORT==== 2007-08-30 16:25:10 ===
I(<0.179.0>:ejabberd_listener:90): (#Port<0.350>) Accepted connection
{{192,168,1,196},50966} -> {{192,168,1,240},5280}

=INFO REPORT==== 2007-08-30 16:25:10 ===
I(<0.172.0>:ejabberd_http:76): started: {gen_tcp,#Port<0.350>}

=INFO REPORT==== 2007-08-30 16:25:10 ===
I(<0.385.0>:ejabberd_http:175): (#Port<0.350>) http query: 'GET' /

=INFO REPORT==== 2007-08-30 16:26:41 ===
I(<0.385.0>:ejabberd_http:175): (#Port<0.350>) http query: 'GET' /index

=INFO REPORT==== 2007-08-30 16:26:48 ===
I(<0.385.0>:ejabberd_http:175): (#Port<0.350>) http query: 'GET' /index.htlm

=INFO REPORT==== 2007-08-30 16:26:52 ===
I(<0.385.0>:ejabberd_http:175): (#Port<0.350>) http query: 'GET' /index.htm

=INFO REPORT==== 2007-08-30 16:26:55 ===
I(<0.385.0>:ejabberd_http:175): (#Port<0.350>) http query: 'GET' /
sasl.log

=PROGRESS REPORT==== 30-Aug-2007::16:12:59 ===
          supervisor: {local,ejabberd_sup}
             started: [{pid,<0.341.0>},
                       {name,ejabberd_mod_pubsub_localhost},
                       {mfa,{mod_pubsub,
                                start_link,
                                ["localhost",
                                 [{access_createnode,pubsub_createnode}]]}},
                       {restart_type,temporary},
                       {shutdown,1000},
                       {child_type,worker}]

=PROGRESS REPORT==== 30-Aug-2007::16:12:59 ===
         application: ejabberd
          started_at: ejabberd <at> ns1
[root <at> ns1 ~]#

many thanks for your time

On 8/31/07, Magnus Henoch <mange <at> freemail.hu> wrote:
> "Gregory Machin" <gregory.machin <at> gmail.com> writes:
>
> > Aug 31 14:00:28 ns1 epmd: epmd: epmd running - daemon = 1
> > Aug 31 14:00:45 ns1 epmd: epmd: epmd running - daemon = 1
> > Aug 31 14:00:48 ns1 epmd: epmd: node name already occupied ejabberd
>
> That's the syslog, right?  ejabberd has two own log files, usually
> called ejabberd.log and sasl.log.  What do they say?
>
> --
> Magnus
> JID: legoscia <at> jabber.cd.chalmers.se
>
> _______________________________________________
> ejabberd mailing list
> ejabberd <at> jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>

--

-- 
Gregory Machin
gregory.machin <at> gmail.com
www.linuxpro.co.za

how does ejabberd_c2s supervisor start?

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Next release time frame

Hi,

I need to update a server from OpenFire to ejabberd.

Via fisheye, I see that a 1.1.4 release is being prepared.

Any ideas when to expect that? I can wait a couple of days before  
upgrading...

Thanks in advance,
--

-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo <at> simplicidade.org
Use XMPP!

Re: priority bug

Badlop wrote:
> 2007/8/31, sergio <ejabberd <at> sergio.spb.ru>:
>> ejabberd allows to set priority outsite char (-128..128) range
> 
> Mickaël Rémond said in the bug tracker:
>> This is not a bug but a feature.
>> 
>> I do not see any good reason to enforce this limitation. It was
>> intentionally left open ended. Some people are using timestamps for
>> example to make sure that their last resource > is the one that has
>> the highest priority.
>> 
>> I am ready to hear explaination of what harm this feature could
>> cause.
> 
> I bring the discussion from the bug tracker to the mailing list
> again, so everybody can participate.
> 
> I guess the opinion of  the author of the protocol in question may be
>  helpful. I'll ping Peter Saint-Andre next monday.

RFC 3921 and rfc3921bis state:

   The OPTIONAL <priority/> element contains non-human-readable XML
   character data that specifies the priority level of the resource.
   The value MUST be an integer between -128 and +127.

If people want some special functionality, we can define a new child
element in a different namespace. After all, the "X" in XMPP stands for
"Extensible". :)

> Anyway, I see two solutions:
> 
> a) Mark the bug as INVALID or WON'T-FIX and reject the patch. If so,
> I strongly recommend to create a new document that describes what 
> inconsistencies are in ejabberd's implementation of protocols.
> Publish it, and add to it any other bug-turns-feature [1]. This way
> other Jabber developers will not be surprised of some particular
> behaviors in ejabberd which are not compliant with standard
> protocols. This will also prevent the bug tracker from being filled
> with many INVALID bugs.
> 
> b) Apply the patch, mark the bug as SOLVED, and also implement a new 
> option to disable this limitation.

I would be in favor of a new protocol extension that enables more
flexible presence priorities / stanza routing. Overloading priority
isn't a good solution.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Re: priority bug

2007/9/4, Peter Saint-Andre <stpeter <at> stpeter.im>:
> I would be in favor of a new protocol extension that enables more
> flexible presence priorities / stanza routing. Overloading priority
> isn't a good solution.

Maybe an idea for a PEP XEP called "User Priority" 

--

-- 
Mvg, Sander Devrieze.

Re: Next release time frame

Hi

ejabberd-1.1.4 is released and installers are available
http://www.process-one.net/en/ejabberd/downloads

regards.