On Wed Sep 8 09:44:48 2010, Iñaki Baz Castillo wrote:
2010/9/8 Kevin Smith <[email protected]>:
> On Wed, Sep 8, 2010 at 9:19 AM, Iñaki Baz Castillo
<[email protected]> wrote:
>> So the server MUST keep all this information forever as it
doesn't
>> know when resource AAA will connect. Am I right? If so, is it a
>> feasible requeriment for a server?
>
> The server could simply send the complete roster, rather than a
delta,
> in which case the server needs to store nothing more than the
current
> version number.
Thanks, but I don't understand how the server could determine when
to
send the complete roster or just incremental changes. For example,
in
the simple case expossed in my initial mail:
1) Bob exists in Alice's roster rev14.
2) In ver15 resource BBB deletes Bob. Let's assume the server
deletes
the item so the most modern rev in the roster is still ver14.
3) Later resource AAA requests roster items modified since ver14.
4) The server matches versions (client verison: rev14, server
version: rev14) so determines that there are no changes to send back
to AAA (ERROR as AAA is not notified about the deletion of Bob).
The solution would be that the server sends AAA the entire roster in
step 4, but based on what?
You'd store a roster as:
<query xmlns='jabber:iq:roster' x237:xmlns='xep-0237-extra-data'
x237:lastdeleted='0'>
<item jid='[email protected]' x237:changed='11'/>
<item jid='[email protected]' x237:changed=14'/>
</query>
Then when bob's deleted, you do:
<query xmlns='jabber:iq:roster' x237:xmlns='xep-0237-extra-data'
x237:lastdeleted='15'>
<item jid='[email protected]' x237:changed=14'/>
</query>
Now in step 4, client='14', so you send the complete roster because
lastdeleted > client.
Obviously if, given the original roster, a client asks for 12, then
lastdeleted <= client, and therefore you send an empty result, and
then push any items where changed > client (if any).
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
