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 <[EMAIL PROTECTED]> 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='[EMAIL PROTECTED]' type='probe'/> > or > <presence to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]' > type='probe'/> > > B) Directed presence saying unavailable then available again. > <presence to='[EMAIL PROTECTED]' type='unavailable'/> > <presence to='[EMAIL PROTECTED]'/> > > C) Subscribe to their presence again. > <presence to='[EMAIL PROTECTED]' 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
