Antone Roundy wrote:
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.
Ok, what if? Do you have any specific use cases where this would be
required with feed linking? And how theoretical are those cases? I
just don't see this as being a practical problem that needs solved right
now.
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".
Of course not.
Feed 1: next >> Feed 2
Feed 2: Feed 1 << prev next >> Feed 3
Feed 3: Feed 2 << prev next >> Feed 4
Feed 4: Feed 3 << prev
It's easy to do this kind of thing.. the challenge I'm having with this
use case is that I don't actually see anyone trying to do this. It's
another "what if" scenario. If this isn't something that someone is
currently trying to do, this is a problem that can easily be solved
later, when it does become an issue. The best we can do now is attempt
to make sure that we don't make it impossible to solve later.
- James
