I had this already:
"Archive document" refers to a feed document that is archived; i.e.,
the set of entries inside it does not change over time. Entries
within an archive MAY themselves change, however.
but if this is catching people by surprise, it obviously isn't
prominent enough. I'll hammer it home with some examples, SHOULDs, etc.
Thanks!
On 2006/05/03, at 3:42 AM, Bill de hÓra wrote:
(ot for the last thread)
Hi Mark,
I've just specced out an app that uses FH and this idea of an
archived feed hadn't quite come across to me as "safe" - I had some
what ifs about server resets that affected the feed.
However, the URL:
http://example.com/feed?start=5&num=10
nails that concern for me and thus your point about "chunky URLs"
which dynamically generated feeds rings true. Would you consider
calling this out thing directly in a future rev? I think it might
be helpful for robust server designs if some guidance were given.
cheers
Bill
Mark Nottingham wrote:
If you use URIs like
http://example.com/feed?start=5&num=10
changing the directionality of "next" and "previous" will not make
what you're doing compatible with feed history.
Such URIs have a much more fundamental problem -- they don't refer
to a stable set of entries, and therefore only act as a snapshot
of the *current* feed, chopped up into chunks. If the feed changes
between accesses, the client will be in an inconsistent state. The
client also has to walk through all of the pages every time it
fetches the feed; it can't cache them -- which is a primary
requirement for feed history.
What are the requirements that drove you to this type of paging
solution?
On 2006/05/02, at 9:14 PM, James M Snell wrote:
Mark Nottingham wrote:
[snip]
As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed History.
Please describe the scenario where you'd want that to happen --
show the
feed.
The feed(s) are part of our open activities implementation and are
available via our APP interop endpoint [1]. Our APP collection
feeds
are also the feeds people subscribe to and search with (e.g. any
of our
feeds accept querystring parameters to filter the feed results).
Requesters can set the page size as a querystring, if the result
set is
larger than the page size, the feed is automatically paged using
first/last/next/previous. The fact that our entries are sorted in
reverse chronological order makes us compliant with APP, but
makes it
impossible for clients to use the Feed History algorithm
(current has a
next but no previous).
- James
[1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
