On Tue Apr 28 10:26:40 2009, Dave Cridland wrote:
FWIW, I'd also suggest adding some text guiding implementors, and
in particular reinstating some text warning against using
timestamps.
I'll write a section for you, possibly even today.
<section1 topic="Implementation Guidelines">
<p>This specification is specifically designed to allow for a wide
range of implementation choices. These range from highly simplistic
but inefficient, to very efficient but quite complex.</p>
<p>This section provides suggestions, rather than instructions, on
some lightweight approaches to conforming with the specification.</p>
<section2 topic="Syntactic Conformance">
<p>A server can conform to this specification by accepting and
ignoring the "ver" element in requests, and providing an empty "ver"
attribute in each roster push.</p>
<p>This provides no efficiency savings for clients.</p>
</section2>
<section2 topic="Exact-match Conformance">
<p>Using some digest (hash) of the roster, a server can identify
unchanged rosters, and handle the case where the client sends a ver
corresponding to the current roster state.</p>
<p>This will account for the majority of cases, and represents a
substantial saving. Server implementors should be careful to
canonicalize the form and ordering of roster items prior to applying
the hash function. This hash function need not be cryptographically
secure, merely resistent to collisions, and it is advisable to pick
one that is fast to compute.</p>
<p>No additional data need be stored, although storing the current
hash will yield some performance advantage. This strategy is thought
to be relatively safe in the face of data loss on the server.</p>
</section2>
<section2 topic="Add-only Conformance">
<p>Using a strictly increasing sequence for the "ver" attribute, a
server can "stamp" each roster item with its last change, and the
roster as a whole with its last deletion. The server either the
entire roster - if a deletion has occured since the client's ver
value - or those changed items.</p>
<p>Deletions are thought to be rare compared to additions and
modifications, and as such this approach captures almost all changes.
The additional storage cost is also low.</p>
<p>Implementors could combine this strategy with the previous one,
detecting a sequence of modifications yielding the same roster as the
client has cached already, by constructing a ver attribute containing
both a hash and sequence value. This may provide some resilience in
the case of data loss.</p>
<p>Implementors should note that a pure timestamp is not suitable
for this approach, since under some circumstances system clocks may
go backwards.</p>
</section2>
<section2 topic="Client Implementation Guidlines">
<p>Client implementors are reminded that the value of the "ver"
attribute is entirely opaque, and they should behave identically with
each strategy described above by simply conforming to the
specification - the only storage requirement for this specification
is the last seen "ver" attribute.</p>
</section2>
</section1>
Useful?
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
