Programming Jabber

Request for roster

It’s easy to guess what the next method call does:

con.requestRoster()

It makes a request for the roster by sending an IQ-get with a query qualified by the jabber:iq:roster namespace:

<iq type='get' id='3'>
  <query xmlns="jabber:iq:roster'/>
</iq>

to which the server responds with an IQ-result:

<iq type='result' id='3'>
  <query xmlns='jabber:iq:roster'>
    <item jid='[e-mail]' subscription='both'/>
    <item jid='[e-mail]' subscription='both'/>
    <item jid='[e-mail]' subscription='both'/>
    ...
  </query>
</iq>

However, as there are no explicit references to the roster anywhere in the script, it’s not as easy to guess why we request the roster in the first place. We know that the client-side copy is merely a “slave” copy, and, even more relevant here, we know that subscription information in the roster <item/> tags is managed by the server—we as a client don’t need to (in fact, shouldn’t) do anything to maintain the subscription and ask attributes and keep them up to date.

So why do we request it? Basically, it’s because there’s a fundamental difference between <presence/> elements used to convey availability information and <presence/> elements used to convey presence subscription information. If John sends Jim availability information in a <presence/> element, whether directly (with a to attribute) or indirectly (through the distribution of that element by the server to Jim as a subscriber to John’s presence), and Jim’s offline on holiday, ...