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.
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.
Are you proposing this instead of the mechanism currently described
in FH? Alongside it?
On 2006/06/07, at 3:35 PM, James Holderness wrote:
Mark Nottingham wrote:
I'm not sure how ETags and 304s come into it -- it sounds like
you're proposing using either the entry-level updated date or the
entry- level id as input to a server-side function to select a set
of entries from the feed. Can you paint out your proposal in
protocol exchanges, please?
Entry-level updated date is close, but not quite what would be
needed. For this to work, it requires that search engines store a
date that represents when a result is "discovered". In other words
the date that an entry is added to the search engine database.
Client connects to server with a specific query.
Server returns the first page of results along with an etag
representing the current internal datetime as accurately as possible.
Client connects to server with "next" link from first page (the
link would obviously have to include the query as well as the page
number).
Server returns the second page of results.
etc.
<wait several days>
Client connects to server with a specific query along with etag
returned from the first query.
Server returns only those results that match the query *and* have a
"discovered" date >= etag date value.
Server also returns etag representing the current internal datetime
as before.
Client connects to server with "next" link from first page (this
link would include the query and the page number, but also the the
etag value).
Server returns the second page of results that match the query
*and* have a "discovered" date >= etag value.
etc.
That make sense?
If the server doesn't have the concept of a "discovered" date, then
there's not much we can do. We can return a paged set of results,
but they can't be updated in any meaningful way so the feed should
not be subscribed to.
Client connects to server with a specific query.
Server returns first page of results along with an etag containing
a hash of the star-spanngled banner.
Client connects to server with "next" link from first page.
Server returns the second page of results.
etc.
<wait several days>
Client connects to server with a specific query along with etag
returned from initial query.
Server notices that there is an etag, doesn't care what it is set
to, and just returns 304 regardless.
In other words, you can retrieve the feed once, but never again.
That's as good as it gets.
Regards
James
--
Mark Nottingham http://www.mnot.net/
