[jdev] That presence problem again

[Nathan Fritz]

I don't see this as being the client's job.  Perhaps the protocol could be
changed to either make more assumptions such as "if the s2s connection is
closed unexpectedly, then the server SHOULD consider all jids connected to
it as offline" and perhaps even the suggestion of "If an available jid has
not sent any presence updates in an hour, the server SHOULD probe for an
update." The protocol provides methods to solve this problem on the server
end.  I don't believe that the client should take it upon itself to nag
about presence, as presence is high traffic enough as it is.

The problem boils down to s2s not having specific recommendations on what to
assume about presence, nor what to do when there are connectivity issues.

On 4/20/07, Robin Redeker <elmex at x-paste.de> wrote:
>
> On Sat, Apr 21, 2007 at 04:38:02AM +1000, Bruce Campbell wrote:
> >
> > This more of a 'what are people doing now' question, not a 'what should
> > the implementations be doing'.
> >
> > Lets say that my Jabber client has an avid desire to know the accurate
> > online status of remote JIDs, and the roster subscriptions are 'both'.
>
> I don't think there is anything wrong or weird with that desire :-)
> It seems to me that this is what XMPP (Extensible Messaging and >Presence<
> Protocol)
> was invented for...
>
> If it is not possible to know a mostly accurate status if anything
> unexpected
> happens (even if the TCP connection breaks I at least know that
> I don't know the presence state), then there is something deeply broken
> :-)
>
> > To that end, my client makes the assumption that if no update to the
> status
> > has been received in an hour, then something has possibly happened to
> the
> > remote JID that hasn't been properly pushed to my client (remote server
> > restart normally ).
> >
> > How should my Jabber _client_ get the latest news about the remote JID?
>
> That is an interesting problem. I'm currently also writing a client
> but I haven't thought of that problem yet. If the remote server reboots
> noone will be noticed of any presence changes (eg. client became
> unavailable).
>
> That indeed means clients have to probe on their own. But the
> RFC unfortunately says: 'probe -- A request for an entity's current
> presence; SHOULD be generated only by a server on behalf of a user.'
> (RFC 3921 2.2.1 Types of Presence)
>
>
> > The solutions that I've tried to get this information are:
> >
> >   A) Presence probes.  Swallowed by some servers.
> >       <presence to='remoteJID at some.where' type='probe'/>
> >       or
> >       <presence to='remoteJID at some.where' from='me at my.domain'
> >       type='probe'/>
> >
> >   B) Directed presence saying unavailable then available again.
> >       <presence to='remoteJID at some.where' type='unavailable'/>
> >       <presence to='remoteJID at some.where'/>
> >
> >   C) Subscribe to their presence again.
> >       <presence to='remoteJID at some.where' type='subscribe'/>
>
> Uh, thats ugly but I like that more than B) or D) :-)
>
> >   D) Unavailable then available again to the entire roster.
> >       <presence type='unavailable/><presence/>
> >
> > Of these, the 'subscribe' trick seems to be the most consistent at
> > returning the desired information.  'probe's seem to get swallowed by a
> > number of servers, and appearing to go offline and online again just
> > irritates the remote users.
>
> Heh, I agree completly that this is indeed not very nice.
>
> > Any other tricks that people use?
>
> I would rather see this issue resolved than seeing 'tricks' that
> 'somehow' work or introduce weird behaviour (like D) or B)).
>
>
> Greetings,
>    Robin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20070420/9ee371ec/attachment-0002.htm>