On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
In section 2.4, would it be easier to implement in existing clients
if:
- The response to the iq/get with version 0 was a full roster, in
the existing format, with the addition of the current version
number
I think it is, isn't it? The spec actually allows a diff from
nothing, but in this instance, it doesn't matter whether it's
technically a "diff" or not, since you'll get full items for
everything that's changed, and everything will have done.
- The response to iq/get could always be a full roster, if the
server got confused in any way, or know that it would be more
efficient to just start from scratch
This is (or should be) the case.
- If the roster has been completely deleted, the response would be
empty, but have version 0
I've a diff for specifying a sequence validity, which changes when
the roster is effectively a new one. (So it'll change if the account
is deleted and recreated, and it'll change if the server is restored
from backup, and it'll change if the server simply can't really be
bothered to use any kind of useful sequence, and instead changes it
on every change).
- The response to iq/get would otherwise be empty, except for the
new version number
- All changes would be sent to the client as roster pushes after
the iq/response, ordered such that the last one had the current
version number
That's quite a neat design. It eliminates the diff attribute.
Then, all I have to do is store my current roster, and apply diffs
to it in exactly one way.
Yes, I like this.
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
