Mark Nottingham wrote:
These are pretty much the assumptions that I was making previously. The degree of precision that FH currently provides isn't desirable for search results. Feed History also requires that the server maintain state about a particular feed, which is unworkable for search results; e.g., to implement feed history for search results, a server would have to mint a whole new set of feed documents for every query, and keep them around.
Not necessarily. They only need to be able to sort results on a most-recently-discovered date. When a client connects to them with an etag representing date X, they return only those results have been discovered since date X. I can believe that there are search engines for which even that isn't feasible, but then FH as we know is not possible, and those feeds are essentially useless from a subscription point of view.
They can still use the paging links so you can connect to a search engine for a once-off paged set of results. They just need to return 304 on any subsequent requests (i.e. anything with an etag) in case someone makes the mistake of subscribing to one of those feeds. If you have something else in mind for that kind of server I'm curious to know what it is. In other words can you envision a server that wants to do paging, doesn't have enough state information to be able to do FH, but still would like to allow subscriptions? How would it work?
This brings me to my other motivation -- I found that most people who use "previous" and "next" don't understand the assumptions that FH makes about archive stability, and point them at URIs like "http:// example.org/feed.atom?page=3".
I don't see how changing the name of the link is going to magically fix that. If people aren't understanding the significance of archive stability, then perhaps it needs to be highlighted more prominently in the FH spec.
That will break the FH algorithm badly
I don't think it's that bad. It loses some of its functionality, but it's no worse than having no paging at all. And you still have the ability to retrieve the full history on first download.
John Panzer wrote:
Our current "previous" links aren't permalinks; they're more like OpenSearch indexes: http://example.org/feed.xml?start=50&len=10. So clients can't usefully cache them the way they could, say, http://example.org/feed.xml?month=may2006.
I understand that, but do you realise that those links are essentially useless for anything other than the first retrieval? As a client there's nothing I can do with them after the first download. I don't have a problem with that if that's all you can do, though. It's still better than no paging at all. And it still works (within the boundaries of what is feasible) using the FH algorithm as it currently stands. I don't see what else you can write into the spec that would make your feed work any better than it currently does.
Regards James
