On 20/07/2005, at 10:44 AM, Thomas Broyer wrote:
I was actually wondering why non-stateful feeds couldn't have
archives:
in the "This month's Top 10 records" feed, why couldn't I link to
"Last
month's Top 10 records"?
If this kind of links are not dealt within feed-history, then I
suggest
splitting the draft into two (three) parts:
1. fh:stateful: whether a feed is stateful or not
2. fh:prev: state reconstruction of a stateful feed
3. (published later) fh:????: link to archives of a non-stateful
feed
(no, I actually don't want such a split, I'd rather deal with the "3."
in feed-history, no matter how)
If we want to solve this "issue" using a distinct element (fh:prev if
fh:stateful=true, fh:???? if fh:stateful=false), is fh:stateful still
needed? The presence of fh:prev would be equivalent to
fh:stateful=true,
the presence of fh:???? would be equivalent to fh:stateful=false, the
absence of both fh:prev and fh:???? would be equivalent to the absence
of fh:stateful, and the presence of both fh:prev and fh:???? would
be an
error.
This is off course true only if fh:prev must be accompanied by
fh:stateful=true. The question is: is it useful to have fh:stateful if
you have no link to any kind of archive?
My main use case for it was to advise aggregators that currently keep
state by default (without being about to walk backwards) that this
isn't appropriate for some feeds. E.g., NetNewsWire, Shrook and many
other aggregators all automatically "remember" a feed's past entries
that it's seen; sometimes, this is undesirable.
Maybe that's biting off too much at once...
Hmm, that seems awfully complex (and hard to grasp -- but maybe
it's just me :) just to avoid a round trip.
One, or a few more... depending on how you archive your entries (daily
archive document, weekly archive document, N entries per archive
document, etc.), how you publish your entries in the subscription feed
(N entries in the feed, or only those entries published during the N
last days), and who frequently you post.
Your subscription feed entries can overlap several archive feeds
and the
fh:prev jump from "archive2.atom" to "archive5.atom". Using "updated",
you can avoid 3 round trips in that case.
...or too many: what if I switch URL addressing scheme (e.g. from
"archive1.atom"..."archiveN.atom" to
"2005/January.atom"..."2005/June.atom")?
A "dumb" reader will retrieve back every archive feed, as it has never
ever dereferenced the URIs.
Well, if you change your archive scheme, you may change other things
too; without more trust between the client and publisher, it probably
*should* go back and fetch everything. This is where client-side
throttling (as discussed before; e.g., "do you really want to go back
that far?") would come into effect.
There are subtle issues introduced when you do time-based comparison
across a network; synchronisation between clocks come into play, and
it gets tricky, if not impossible, to specify correct behaviour.
Couldn't much the same effect be achieved by saying that
implementations can use other mechanisms (e.g., updated in the
archive itself, the id in the archive) to ascertain whether it's seen
something before? You'd still have one extra fetch, but that's not
nearly as big a deal as walking back the entire feed (which I agree
would be a problem).
Cheers,
--
Mark Nottingham http://www.mnot.net/
