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
unique."
+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
bootstrap.
Or omit the version maybe?
No, omitting the version means "I'd like the full roster and I do not
understand versions".
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
"Processing" group.
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.
--
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
