I get the feeling that we should perhaps first list the main types of
history archives, and
then deal with each one separately. I can see 3:
1- The top 20 list: here one wants to move to the previous top
20 list and think of them
as one thing. The link to the next feed is not meant to be
additive. Each feed is to
be seen as a whole. I have a little trouble still thinking of
these as feeds, but ...
2- The history of changes link: the idea here is that a feed is
a list of state changes
to web resources. The link to the history just increases the
length of the feed by
pointing to the next feed page. These two pages could have
been merged to create one
feed page with the same end result. By moving back through the
feed history one gets
to see the complete history of changes to the resources
described by the feed.
3- A listing of the current states of the resources: here the
end user is searching for
all the blog entries as they currently are. No feed id is ever
duplicated across the chain.
I think each of these has its uses.
1. this use case is clear and well understood.
2. is very useful for 'static' blog feeds written from a remote
server, as once a feed has
been archived it no longer needs to be rewritten. It is also
very useful in helping a
client synchronize with the changes to the feed. If a client is
off line for a few months
or if there are a lot of changes in a feed then the client just
needs to follow this type
of link to catch up with all the changes. If the entries are
describing state changes to
resources such as stock market valuations, then this would allow
one to get all the
valuations for a company going back in time.
3. It is easier for this to be generated dynamically upon request.
It is not really a history
of changes, but rather a list of resources. In a feed concerning
a blog these two can of
course easily be confused as we think of blogs as being created
sequentially. We then think
of the feed history as the history of the blog entry publication
dates. If an old blog entry
gets changed then the page on which that blog entry originally
appeared in the feed would
get changed just as the permalink to the blog post itself gets
changed.
This type of list is of course not very useful in keeping
someone updated as to the changes
in a feed, as the whole linked feeds would need to be stepped
through to see if anything has
changed.
I think it is with this version that the proposals of having a
separate document that points
to all the entries makes most sense. And this case also seems to
be worked upon in the API
I think.
more below...
On 23 Jul 2005, at 18:14, Mark Nottingham wrote:
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.
So is it that MT can only generate feed links such as describe in 3
above?
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.
Well in many cases this is exactly what I want. If someone makes a
big change to a resource that
was created one year ago (say your first blog post) then I think this
is well worth knowing about.
Especially if I have written a comment about it. Of course if the
change is not *significant* then
the change to the old feed archive would not be significant either.
So perhaps I should have said
that archives should not change in any *significant* way.
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.
And I agree. The way you dealt with that problem was by adding a
special flag for that case.
We can create a special flag for the other cases too...
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.
yes. But we don't have to answer all questions. We can just decide on
some problem we want
to solve, delimit it clearly and solve it. No?
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.
It there a place where these problems are clearly layed out so that I
can get a comprehensive
view of them?
Thanks,
Henry Story
Cheers,
--
Mark Nottingham http://www.mnot.net/
