Mark Nottingham wrote:
Are you talking about using ETag HTTP response headers, If-Match request headers, and 304 Not Modified response status codes? That's a gross misapplication of those mechanisms if so, and this will break intermediaries along the path.
For the first page I'm talking about an Etag (or Last-Modified) HTTP response header and If-None-Match (or If-Modified-Since) request headers for the retrievals a month later. For page two onwards the state information (date, query and page number) comes from the link urls returned by the first page. I don't see how that's a gross misapplication of those mechanisms, but I'll take your word for it.
Even if it's cast as a query parameter in the URI (for example), it requires query support on the server side, a concept of "discovered time" (as you point out), and places constraints on the ordering of the feed.
The ordering is not necessarily important. As long as the server can filter out entries that don't match a specific time criteria it can return those entries in any order.
Are you proposing this instead of the mechanism currently described in FH? Alongside it?
What I'm proposing would work with the FH as currently specified as long as the client supported ETag or Last-Modified as well. For me that means no change at all.
And I'm not trying to propose this as something that servers have to do. It just seemed to me to be a fairly easy way for a search engine to support subscribable paging if they chose to. And it should work with clients that already support FH so it doesn't require any new links or algorithms.
If you have something better in mind that's cool too. So far the plan seems to be:
1. Change the names of the link relations so as to break existing clients. 2. ??? 3. Profit!! Regards James
