[ejabberd] Modify presence probe response for offline clients

Peter Saint-Andre stpeter at stpeter.im
Mon Dec 15 20:23:21 MSK 2008


Badlop wrote:
> On Mon, Dec 15, 2008 at 4:43 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> Evgeniy Khramtsov wrote:
>>> Since we already store user's status info in mod_last, additional
>>> storage of *full* XML stanzas looks like an overhead.
>> So the server has what it needs -- it just needs to pull the answer out
>> of a different table if the user is offline.
> 
> ejabberd doesn't store all the information required. Let's see what we
> have and what we want:
> 
> 1.  For XEP-0012 ejabberd only stores the timestamp and status of last
> unavailable presence. The full XML of last presence is not required,
> so it isn't stored.
> 
> http://xmpp.org/extensions/xep-0012.html
> 
>> When returning an IQ-result, the target entity sends an <iq/> stanza of type='result'
>> containing a <query/> element with a REQUIRED 'seconds' attribute
>> and OPTIONAL XML character data.
> 
> Example 5:
> <iq from='juliet at capulet.com'
>     id='last1'
>     to='romeo at montague.net/orchard'
>     type='result'>
>   <query xmlns='jabber:iq:last' seconds='903'>Heading Home</query>
> </iq>
> 
> 
> 2. RFC 3921 says:
> 
>> the server MUST either
>> (1) reply to the presence probe by sending to the user the
>> full XML of the last presence stanza of type "unavailable"
>> received by the server from the contact, ...
> 
> It isn't possible to provide the full XML, because it isn't stored currently.
> 
> 
> 
> Some solutions:
> 
> 1. Update client to query iq:last, as Evgeniy proposed.
> 2. Write a custom module that stores full XML of unavailable presence,
> and a patch so ejabberd provides that answer.
> 3. Write a patch so ejabberd rebuilds a (potentially incomplete) full
> XML with the information it stored for XEP-0012.
> 4. Write a patch so, instead of returning full XML as stated in RFC,
> ejabberd returns only a response similar to iq:last: seconds and
> status.
> 
> Solution 1 is standard compliant and doesn't require additional
> storage in the server.
> Solution 2 requires changes in ejabberd and additional storage.
> Solutions 3 and 4 are not RFC compliant.

#1 also introduces an extra round trip, and the need for a timeout of
some kind (when does the client start sending iq:last requests?).

#4 would be fine with me, and I'd be willing to adjust the rule in
rfc3921bis so that the full XML is a SHOULD, not a MUST. I think that
returning the last presence (*some* last presence) is better than
returning no presence and forcing the client to query for it.

Peter



More information about the ejabberd mailing list