James Holderness wrote: > > 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.
Yes, but that's orthogonal to paging. > 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. I have the same definition. >> 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. You're describing the PubSub behaviour, which is not IMO a "search engine" but an aggregator with filtering capabilities. PubSub filters are quite similar to the "category feeds" you see sometimes: "I don't want the whole blog entries, just the ones belonging to that category, or tagged with that word". With PubSub, you say "I don't want the whole web entries, just the one matching that filter". You're not describing a "search feed" (or maybe more a search *result* feed, like OpenSearch result feeds) but a "filtered aggregate feed" (as published by PubSub). >> 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. Wait a bit and I'll propose them for registration. When they'll exist, what would become your argument? > 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. But we also want paged non-incremental feeds (OpenSearch result feeds), while "non-incremental feeds with history" have not yet proven to be needed. You're trying to describe "incremental feed paging" and "navigation through non-incremental feed snapshots" with the same link relation. When people will want "non-incremental feed paging" (and this is already a need), we'll have two link relations related to paging (for incremental and non-incremental feeds) and one that can also be used to navigate into non-incremental feeds history. Here's a chunked incremental feed (each chunk has 10 entries): 1 11 21 31 41 51 61 71 81 |----|----|----|----|----|----|----|----|----| ^ ^ `----' This is a chunk. present <------------ time -------------> past previous/next link from chunk to chunk. Entries are added into or before the #1 chunked above. Here's a chunked non-incremental feed (e.g. OpenSearch result feed; each chunk has 10 entries): 1 11 21 31 41 51 61 71 81 |----|----|----|----|----|----|----|----|----| ^ ^ `----' This is a chunk. ++ <------------- relevance --------------> -- previous/next link from chunk to chunk. Here are non-chunked non-incremental feeds (e.g. Top 10 feeds with history): 1 |----| -> Oct. 24 Top 10 1 |----| -> Oct. 17 Top 10 1 |----| -> Oct. 10 Top 10 previous/next would link from snapshot to snapshot ?! And finally, here are chunked non-incremental feeds (e.g. Top 50 feeds with history, each chunk has 10 entries): ++ <-------------- ranking ---------------> -- 1 11 21 31 41 51 61 71 81 |----|----|----|----|----|----|----|----|----| -> Sept. 2005 ^ ^ `----' This is a chunk. 1 11 21 31 41 51 61 71 81 |----|----|----|----|----|----|----|----|----| -> Aug. 2005 1 11 21 31 41 51 61 71 81 |----|----|----|----|----|----|----|----|----| -> Jul. 2005 What would mean previous/next here? I'm proposing previous/next linking from chunk to chunk inside the same snapshot and adding a new link relation (or set of link relations) for linking from snapshot to snapshot. Do you now see what I'm talking about? -- Thomas Broyer
