Thomas Broyer wrote:
As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:[EMAIL PROTECTED]"previous"] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft.
I beg to differ. I think the incremental state of a feed is very relevant to paging. If the aggregator does not know that a feed is non-incremental it will not be able to process the feed document in a meaningful manner. And when I say non-incremental I mean something like a "Top 10" list where the entries in the feed document are a complete replacement for any entries that the aggregator may have previously received from that feed.
What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds?
Not necessarily, no. A search feed could quite easily be implemented as an incremental feed. This is the most sensible approach since it would allow the feed to be viewed in all existing aggregators without requiring a special knowledge of non-incremental feeds.
The initial feed document consists of all known results at the time the search is initiated. As new results are discovered over time, the feed can be updated by adding new entries to the top of the feed in much the same way that new entries would be added to the top of a blogging feed. In fact, if you do a search with something like feedster, this is exactly the sort of feed you will get back.
Once you add paging support, the search results can be split over multiple pages in much the same way that an incremental feed splits its entries over multiple archives. As long as the search feed adds new entries to the top of the subscribed document and moves older results into archives as they fall out the bottom, it can be processed in exactly the same way as a regular incremental feed.
However, an incremental feed could take advantage of differentiating between paging and "archive linking": if linking to archives uses an atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed "pages". Each "archived set of entries" could for example cover one or two week, so a user could navigate through the "feed state" or "feed history" not only by going from pages to pages but also by accessing archived chunks via an "index" or "table of contents".
This is all very interesting, but not possible without more link extensions which don't exist yet. With what we have so far we can do incremental feed archives; we can do at least some form of searching; we can do non-incremental feeds (of the "Top 10" variety) with history. I think that's a good start.
Regards James
