Definite +1
On 6/6/06, Mark Nottingham <[EMAIL PROTECTED]> wrote:
I've been talking to a number of people face-to-face about Feed History and the use cases for it, and I've come to a position where I believe there are two major use cases out there for putting together multiple feeds to form one big, virtual feed. 1) So-called "incremental" feeds, where changes are happening at the "front end" of the feed, while less recent entries are pretty much static. If a change is required in an old entry, either a new revised entry with the same ID, or something like a tombstone is required. Publishers can easily make stable archives of old entries available, and clients wish to take advantage of caching, etc. to avoid re- transferring old entries again and again. A high degree of fidelity may be required; e.g., it should be possible to accurately reconstruct the entire state of the feed with no missed entries. E.g., a blog feed, but this could also be seen as an "event feed", where the entries are changes to the state of the underlying resources. 2) So-called "paging" feeds, where the entries are often the results to a query, being paged through in groups so as to not overwhelm the server and/or communications link. Entries may be arbitrarily added, deleted and reordered. Clients expect to access what the portions they need in relatively quick succession, and do not require absolute fidelity. E.g., OpenSearch query results. The entries in the feed directly correspond to the underlying resources, 1-to-1. These are very different things. Incremental feeds require that the server keep state around per-feed, which isn't viable for something like query results, but fine for a blog. Paging feeds can lose entries (e.g., if http://example.org/index.page?page=1 refers to http://example.org/index.atom?page=2, page 2's contents can change between the two fetches), which is OK for some applications, and not for others. As such, I'm pretty much convinced that they need to be dealt with separately. Originally, I proposed that Feed History use "prev-archive" link relations, but many people pushed back on that in favour of the more generic "previous" and "next". Given the above, I'd like to see if anyone would still object to having separate relation sets for incremental feeds ("prev-archive" and friends) and paging feeds ("previous", "next" and friends). If people think that's a good idea, I can prepare a new draft that attempts to address both. The intent would be to be compatible with current usage by OpenSearch, GData, etc., while giving people the option to use something more reliable when necessary. Thoughts? -- Mark Nottingham http://www.mnot.net/
-- <M:D/> M. David Peterson http://www.xsltblog.com/
