On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still means that clients need to check the
first fh:prev document if they know all entries there - if my
understanding is correct.
This is one of the unanswered questions that I left out of scope. The
consumer can examine the previous archive's URI and decide as to
whether it's seen it or not before, and therefore avoid fetching it
if it already has seen it. However, in this approach, it won't see
changes that are made in the archive (e.g., if a revision -- even a
spelling correction -- is made to an old entry); to do that it either
has to walk back the *entire* archive each time, or the feed has to
publish all changes -- even to old entries -- at the head of the feed.
I left it out because it has more to do with questions about entry
deleting and ordering than with recovering state. it's an arbitrary
decision (I had language about this in the original Pace I made), but
it seemed like a good trade-off between complexity and capability.
Does that make sense, or am I way off-base?
Is it worthy to think of something to spare clients and servers
this lookup? Are the HTTP caching and If-* header mechanisms good
enough to save network bandwidth?
An alternate stragety would be to require that fh:prev documents
never change once created. Then a client can terminate the sync
once it sees a URI it already knows. And most clients would not do
more lookups than they are doing now...
--
Mark Nottingham http://www.mnot.net/
