(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/
