2006/6/8, James Holderness <[EMAIL PROTECTED]>:
Thomas Broyer wrote: > 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?
Sorry, I thought you wanted search engines to produce "snapshots"... (side note: but in this case, is there a need to pass a "date" parameter to following pages? and if pages are kind of "live", isn't there a risk of data loss? –I mean, this is the Web, so you'll end up doing the request for each page, just returning different chunks of the result set; if an entry changes between the request to the first page and the retrieval a following page, your request might put it somewhere else in the result set, changing ordering of entries based on updated time stamps, "discovery date", ranks or else, so your chunks would be different than if the entry hadn't changed, and an entry that have not been retrieved might end up in an already retrieved "chunk by page number", hence the client missing an entry– I think this is Mark's concern: this might be an acceptable behaviour in some cases but not 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.
OK, I though you only supported Etags, as defined by HTTP/1.1 for efficient caching and bandwidth saving.
> 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.
Yep, sorry, this is not a problem.
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).
So we agree ;-) Could you read my recent mails in this thread and confirm that it's the case?
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.
So there now are two -1, isn't it? ;-) -- Thomas Broyer
