On 19/07/2005, at 2:04 AM, Henry Story wrote:
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 very much agree that this is the ideal that should be striven for.
However, there are some practical problems with doing it in this
proposal.
First of all, I'm very keen to make it possible to implement history
with currently-deployed feed-generating software; e.g., Moveable
Type. MT isn't capable of generating a feed where changed entries are
repeated at the top out of the box, AFAIK.
Even if it (and other software) were, it would be very annoying to
people whose feed software doesn't understand this extension; their
"show me the latest entries in the blog" feed would become "show me
the latest changed entries in the blog", and every time an entry was
modified or spell-checked, it would show up at the top.
So, it's a matter of enabling graceful deployment. Most of the reason
I have the fh:stateful flag in there is to allow people to explicitly
say "I don't want you to do history on this feed" because so many
aggregators are already doing history in their own way.
The underlying problem, I think, is that different feeds have
different semantics. Some will want every change to be included,
others won't; for example, a blog probably doesn't need every single
spelling correction propagated. There are some fundamental questions
about the nature of a feed that need to be answered (and, more
importantly, agreed upon) before we get there; for example, we now
say that the ordering isn't significant by default; while that's
nice, most software is going to infer something from it, so we need
an extension to say 'sort by this', *and* have that extension widely
deployed.
I tried to approach these problems when I wrote the original proposal
for this in Pace form; I got strong pushback on defining a single
model for a feed's state. Given that, as well as the deployment
issues, I intentionally de-coupled the state reconstruction (this
proposal) from the state model (e.g., ordering, deletion, exact
semantics of an archive feed, etc.), so that they could be separately
defined.
Cheers,
--
Mark Nottingham http://www.mnot.net/
