Am 18.07.2005 um 23:21 schrieb Mark Nottingham:
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.
It is a valid starting point. I am just wondering what consequences it
has on client implementations. Let's say CNN goes stateful, how would a
client handle a history which soon consists of thousands of entries.
How would a server best offer such a history to avoid clients
retrieving it over and over again. Probably nobody has a good idea on
that one, or?
I have the feeling that clients will need to protect themselves from
servers with almost infinite histories. So a client will probably offer
a XX days into the past, max NN entries setting in its UI. Maybe that
is all that's needed.
How about:
"In case feeds are served via HTTP, server implemenations SHOULD offer
ETag and Last-Modified headers on history documents (see RFC 2616 xxx).
Clients SHOULD persist ETag and Last-Modified information and use If-*
headers to ease server load on history synchronization."
//Stefan
