[standards-jig] Presence priority finetuning

Julian Missig julian at jabber.org
Tue Jul 2 15:36:45 UTC 2002


On Tue, 2002-07-02 at 10:59, Sami Haahtinen wrote:
> On Mon, Jul 01, 2002 at 04:07:02PM -0400, Julian Missig wrote:
> > On Mon, 2002-07-01 at 15:57, Sami Haahtinen wrote:
> > > On Mon, Jul 01, 2002 at 03:45:20PM -0400, Julian Missig wrote:
> > > > On Mon, 2002-07-01 at 15:41, Sami Haahtinen wrote:
> > > > > before the server sends the offline messages, it needs to know wether
> > > > > the client will accept them, if you think about it this way, the client
> > > > > has to negotiate the accepted messages before sending it's first
> > > > > <presence/> to make sure that the server only sends the messages that
> > > > > this client accepts certain types of messages.
> > > > 
> > > > ... so?
> > > > There's nothing saying a server can't browse you right after you
> > > > connect, before you even send a presence packet. Or the server could
> > > > wait on sending the messages until after it attempts to browse you.
> > > 
> > > this brings us to yet another problem.. how long should the server wait
> > > for a reply from the client, atleast a quick check with gabber revealed
> > > what i was expecting.. nothing is returned when a query is sent to the
> > > client which it does not understand.. (and to me, Gabber behaved as
> > > expected)
> > > 
> > > how long should the server wait for a valid reply before dumping the
> > > data according to default rules?
> > 
> > Well, technically clients should be returning a Not Supported iq if they
> > don't support a particular namespace. We could always move to enforce
> > this. Or the browse could be before the <presence/> is sent, like I
> > said. So if a client sends presence, it is assumed it doesn't support
> > browse unless it says otherwise.
> 
> when done this way, how long should the client wait for a valid
> request? I'm guessing now, but there must still be 1.2 (or earlier)
> servers out there, this will be the casea long time after the first
> release of a server that supports this. how would the client know that
> tis server actually doesn't support browse/disco and will never send the
> request..
> 
> > The true solution is to get browse/disco standardized (and pick one over
> > the other) and required...
> 
> also, this morning while i was in the shower (what a excellent place to
> think =) i came to think that disco or browse wouldn't actually work too
> well with this.. browse works with namespaces and disco works with
> aliases, we are back with the original problem where the server had to
> know all possible packets that can be passed through it..
> 
> i came to think of something like this (adapt this to some JEP if you
> find one)
> 
> Client connects and sends this to the server to check that it supports
> message rules..
> 
> <iq id='r1' to='server' type='get'>
>   <query xmlns='jabber:iq:rules'/>
> </iq>
> 
> ofcourse, the server would reply with either an error or with the
> current rulesets.
> 
> <iq id='r1' to='user at server/resource' type='result'>
>   <query xmlns='jabber:iq:rules'>
>     <default/>
>   </query>
> </iq>
> 
> next the client tells the server that it wants (all) headlines and chats
> if there are no clients with a higher priority , but no normal messages
> and the set queries with the FOOBAR namespace.
> 
> <iq id='r2' to='server' type='set>
>   <query xmlns='jabber:iq:rules'>
>     <message type='headline' priority='inf'/>
>     <message type='chat' priority='5'/>
>     <message type='normal' prority='none'/>
>     <iq>
>       <query xmlns='FOOBAR' priority='5'/>
>     </iq>
>     <default priority='1'/>
>   </query>
> </iq>
> 
> and the server would ofcourse reply to that..
> 
> <iq id='r2' to='user at server/resource' type='result'/>
> (is there a need to repeat the query?)
> 
> after this is done the client will send the <presence/>, This way the
> server does not have to know all data that is passed through the server
> and the client would be left with full control how to delegate the
> messages.

This is exactly what I want to avoid, though. There are now *4* new
messages which need to be sent for this simple "hey, I want this stuff"

Julian





More information about the Standards mailing list