On 18 Jul 2005, at 23:21, Mark Nottingham wrote:
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.
Clearly the archive feed will work best if archive documents, once
completed (containing a
given number of entries) never change. Readers of the archive will
have a simple way to know when
to stop reading: there should never be a need to re-read an archive
page - they just never change.
The archive provides a history of the feed's evolution. Earlier
changes to the resources
described by the feed will be found in older archive documents and
newer changes in the later
ones. One should expect some entries to be referenced in multiple
archive feed documents. These
will be entries that have been changed over time.
Archives *should not* change. I think any librarian will agree with
that.
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 stratgey 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...
I think this would be the correct strategy.
Henry Story
