I have to warn you, this will get somewhat rambling...
On Wed Nov 18 23:20:40 2009, Peter Saint-Andre wrote:
I've added text about the 'ver' attribute to XEP-0060. It's perhaps
a
bit underspecified right now. Feedback welcome. See also:
Hmmm... I think that using a roster versioning scheme may prove
problematic. One of the nicer parts of that design is that it allows
(in various ways) a rapid resync of state, whereas the notion of
"catching up" on a pubsub node may be slightly different.
Roster versioning is, however, a great fit if we're using pubsub
nodes as storage - the trouble is that roster versioning assumes,
quite reasonably, that deletion is rare, additions more common, and
no change at all is the most common case.
I'm less than convinced that's a reasonable assertion with pubsub
nodes - change is, I'd expect, typically more commonplace. Deletions
are very common - historical items are removed, etc.
But it's the key feature of pubsub nodes that concerns me most -
there's more than one of them. With rosters, every user has just one
roster - even if a few of us have been discussing having more, the
numbers are still vanishingly small.
With just simple PEP, there's hundreds of nodes I subscribe to, and
sending a ver string to each of them to resynchronize - in the name
of efficiency, no less - seems like a bad idea.
In particular, I don't see the fundamental advantage of not simply
requesting (or receiving automatically, for PEP) all items in the
node at the beginning of each session. In certain pathological cases,
this may be considerably more bandwidth, but in no case will it save
round-trips.
Where we *do* need to specifically request all items, it seems
reasonable to include a roster versioning style ver string - it will
save quite a few octets on a request we'll be making anyway, on nodes
which are likely to be heavyweight pubsub nodes.
On the other hand, I don't think this mechanism is suitable for PEP,
and other pubsub services where there is a presence relationship. In
these cases, it seems logical to consider some alternatives, probably
based on presence.
I'm not sure, yet, whether there's a mechanism that will work for
both cases.
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
