On Mon Mar 10 20:32:17 2008, Dave Cridland wrote:
On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
- 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.
But then I thought a little harder whilst finishing cooking.
1) How does the client know that it's got all the updates?
2) Doesn't this mean that every roster push has to be acknowledged?
Doesn't this increase the transmissions required from a client? (Note
that the client cannot pipeline them all into the same TCP packet,
because of (1) - otherwise, it'd presumably compress well).
So I think yes - easiest to get rapid deployment, but no - it's much
harder to get a quality implementation.
You can take our existing "diff" format and push each item through
your internal roster push handling, incidentally. Not much
refectoring involved, although certainly more than your design, but
you get a clean protocol at the end of it.
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
