On 2006/06/07, at 11:16 AM, James Holderness wrote:
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?
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?
--
Mark Nottingham http://www.mnot.net/
