Hi,
On Mar 4, 2008, at 10:27 PM, Dave Cridland wrote:
On Tue Mar 4 21:54:31 2008, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Roster Versioning
Abstract: This specification proposes a modification to the XMPP
roster management protocol to support versioning of rosters for
more efficient downloading of the rost er information.
URL: http://www.xmpp.org/extensions/inbox/roster-versioning.html
[...]
"The value of the 'version' attribute MUST start at zero (0) and
MUST be incremented by one (1) for each change to the roster."
I would personally prefer that this read:
"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."
(Insert RFC 2119 language to suit).
My reasoning is:
a) Servers might need to increase it by more than 1 for some
changes, if they're not performed atomically.
b) Servers may need to increase it for changes which are not user-
visible, such as the from-pending state.
c) We might need to change it in the future for other purposes.\
+1. I can't see any reason for the spec to require more than a
increasing version number.
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?
Sections 2.4/2.5 contain no closing </query>, and don't show
groups, etc. Both need to specify that the complete roster item is
used.
+1 for groups.
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.
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?
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
