On 14/10/2005, at 8:01 PM, James Holderness wrote:
I never did understand this. Why is fh:incremental needed here?
From a feed history point of view you either have a history (a prev
link is present) or you don't. That's all an Atom processor needs
in order to reconstruct the feed.
I get that a feed producer may want to provide a non-incremental
feed (top 10, todo lists, playlists, etc), but I don't see what
that has to do with feed history. Wouldn't that be better suited in
a separate extension along with whatever other meta-information
might be appropriate for non-incremental lists?
It's more relevant than it seems at first glance. Currently, most (if
not practically all) feed aggregators will keep a history by default,
without information otherwise. Introducing a standard extension to
enable that necessitates that there be a way to say "don't do that."
The only dangling point is "first." I'm not especially against
it, but what's the use case?
I'm not especially for it, but it's theoretically possible that
someone subscribing to a feed for the first time may want to
download the full archives. Depending on their processing model,
this may be more convenient starting with the oldest archive and
working forwards in time
Yeah, that's pretty much where I'm at; supplying effectively gives
*two* ways to reconstruct the state of a feed, meaning that both
would need to be supported (and optimised) by implementations, which
isn't so great unless there's a compelling need for it.
--
Mark Nottingham http://www.mnot.net/
