[Standards] Proposed XMPP Extension: Roster Versioning
dave at cridland.net
Wed Mar 5 09:10:08 UTC 2008
On Tue Mar 4 23:48:53 2008, Pedro Melo wrote:
> On Mar 4, 2008, at 10:27 PM, Dave Cridland wrote:
>> "The value of the 'version' attribute is an integer value which is
>> increased with any change to the roster, whether or not the
>> client supports this extension. In particular, the 'version'
>> attribute contained in roster pushes (see Section 2.5) MUST be
> +1. I can't see any reason for the spec to require more than a
> increasing version number.
The key phrase "strictly increasing sequence number" needs to be
present somewhere, to keep mathematicians happy. ("Monotonically
increasing" varies in its meaning in different parts of the world,
bizarrely, so there's a phrase to avoid).
>> Section 2.2:
>> Include some text saying that clients can set version to 0 if they
>> have no roster cached with a version - otherwise there's no
> Or omit the version maybe?
No, omitting the version means "I'd like the full roster and I do not
>> Section 2.4 needs to include a method for servers to indicate
>> whether this is an update, or a complete replacement.
> Why? A complete replacement is just a full set of updates. The
> final XML would be equivalent. From the client perspective, he
> would replace all the cached local entries.
No, it isn't. There's that "removed" value for subscription. In the
case where a full update is needed, it's quite likely that one of the
reasons is because the server can't remember all (or any) deletions.
If a full update looks the same as a diff, then a client cannot know
to remove otherwise undead entries.
>> Finally, I'd include an assertion for roster sets - so that a
>> client can perform actions such as a "set if not changed since".
>> Dead easy for servers, I think.
> I don't follow what this is. Can you elaborate with a use case?
It is, as PSA suggested, just a convenient place to put a potentially
cool feature. I'm far from wed to it, but it'd be nice to at least
keep it in mind.
But, let's say that you had a bot which processed all entries in it's
roster. Let's further complicate things by having multiple instances
of the bot, because it's a CPU heavy bot. Now, it can do work by:
1) Finding all entries not in the "Processed" group.
2) Doing a conditional modify of the roster, placing an entry into a
3) If that succeeds, process, then place it (unconditionally) into
the "Processed" group.
4) GOTO 1 (Gotta love that BASIC).
There's far simpler use-cases, such as adding a group. (The client
cannot add a group, it can merely change groups, so to add one
without potentially removing a newly added one, it must ensure
nothing else has changed the roster since it last operated.)
For both these use-cases, it would imply that we could specify this
slightly tighter, and insist that each roster entry has a sequence
value visible to the client. I can't think of a sane server
implementation that wouldn't do this anyway.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards