[jdev] That presence problem again

[Robin Redeker]

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