On Oct 17, 2005, at 5:17 PM, Mark Nottingham wrote:
They seem similar. But, what if you want to have more than one
paging semantic applied to a single feed, and those uses of paging
don't align? I.e., there's contention for prev/next?
If no one shares my concern, I'll drop it... as long as I get to
say "I told you so" if/when this problem pops up :)
I share your concern.
On 17/10/2005, at 3:21 PM, Thomas Broyer wrote:
I don't think there are different concepts of paging.
Paging is navigation through subsets (chunks) of a complete set of
entries.
Yeah, but what if you need what amounts to a multi-dimensional
array. The method of addressing each dimension has to be
distinguishable from the others.
If the complete set represents all the entries ever published
through an ever-changing feed document (what a feed currently is,
you subscribe with an URI and the document you get when
dereferencing the URI changes as a sliding-window upon a set of
entries), then paging allows for feed state reconstruction.
In other terms, feed state reconstruction is a facet of paging, an
application to non-incremental feeds.
Let's say you're doing a feed for the Billboard top 100 songs. Each
week, the entire contents of the feed are swapped out and replaced by
a new top 100 (ie. it is a non-incremental feed). And let's say you
don't want to put all 100 in the same document, but you want to break
it up into 4 documents with 25 entries each. You now have two
potential axes that people might want to traverse--from songs 1-25 to
26-50 to 51-75 to 76-100, or from this weeks 1-25 to last weeks 1-25
to two weeks ago's 1-25, etc. You can't link in both directions with
the same "next".
There are clearly two distinct concepts here--navigating through the
chunks that make up the current state of the feed resource, and in a
non-incremental feed, navigating though the historical states of the
feed resource.
