Thomas Broyer wrote:
What you described is RFC3229 w/ feeds [1], but you failed to include
the new request and response headers and the specific status code,
which are necessary because you're changing the behaviour of
If-None-Match and 304 (Not Modified) as defined in HTTP/1.1.
Yep. Sorry, forgot to mention that.
That means you need to keep entry revisions as well, so that if an
entry is updated while a client is navigating the paged result set, it
is sent the "old" revision (corresponding to the "date" parameter).
Why? If an entry has been revised either don't send it (they'll get it then
next time they refresh), or send it anyway (they'll just get it again the
next time they refresh).
Is that such a big deal? Or am I missing something?
Yes, ordering is not important. If ranking is necessary, then use the
Feed Rank extension (but that means that potentially a great number of
entries will be sent back as "modified" in 226 (IM Used) responses
just because their ranking has changed)
I would have thought IM only applied to the first page. All subsequent pages
have a specific query that includes the query, page and time. You're not
sending back a partial result in that case.
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.
You're trying to change HTTP/1.1 behaviour wrt the If-None-Match
request-header field and the 304 (Not Modified) status code, so you
need to implement RFC3229 w/ feeds (which means dealing with some new
headers and a new status code).
No change at all for *me*. As in my client. I already support FH. I already
support Etags. I already support 3229.
As I already said, I highly suggest not using paging for 226 (IM Used)
responses and rather fall back to "standard GET" in case there are too
many changes (i.e. behaving the same way as servers that don't support
RFC3229 w/ feeds).
I don't get why this is a problem, but if you don't like it don't use it.
All I'm saying is, if you're a search engine and you what to create
subscribable paged results, this is a method that you can use right now, and
it will work with at least one existing FH capable client (I suspect others
too). The other proposal on the table is to change all your link names.
Arguably a much better proposal than what I'm offering - it certainly seems
to have got a lot of +1s - but it will work with precisely no one.
Regards
James
