Any extension that uses "previous" and "next" has to account for the
stablity of the underlying resources; if you use *any* paging
application and the set of entries in "previous" and "next" changes
over time, you're going to potentially end up with a reconstructed
feed in inconsistent state. Or do you have use cases where it's OK to
have sloppy feed reconstruction?
On 2006/05/03, at 8:43 AM, James M Snell wrote:
+1, I'd also highly recommend introducing an "archive" link relation
that can be used to cleanly separate paged feed documents used for
state
reconstruction from paged feed documents used for other purposes (e.g.
searching)
===
Attribute Value: archive
Description: A URI that, when dereferenced, returns a feed document
containing a fixed set of entries that does not change over time.
Expected display characteristics: The archive relation may be used
for background processing without displaying its value, or, a user
agent may support displaying a hyperlink, button or other GUI
element
for accessing or subscribing to the linked feed document.
Security Considerations: Automated agents should take care when this
relation crossed administrative domains (e.g. the URI has a
different
authority than the current document)
===
Example;
<link rel="archive" href="http://example.org/archive?
when=2006/04" />
- James
David Powell wrote:
Wednesday, May 3, 2006, 6:48:55 AM, 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.
I think it would be worth recommending the use of stable URIs in the
draft.
--
Mark Nottingham http://www.mnot.net/
