[ejabberd] Modify presence probe response for offline clients

Badlop badlop at gmail.com
Mon Dec 15 19:39:20 MSK 2008


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.


---


More information about the ejabberd mailing list