- From: James Snell <jasnell@gmail.com>
- Date: Mon, 5 Dec 2011 16:32:34 -0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Ok... updated the draft based on much of the feedback provided. There will be another round of changes coming. Hopefully I've adequately addressed most of the concerns raised so far. http://tools.ietf.org/html/draft-snell-http-prefer-05 - James On Mon, Dec 5, 2011 at 3:50 PM, James Snell <jasnell@gmail.com> wrote: > Oh.. the conditional request is definitely an interesting case. I'd > definitely be open to adding some additional discussion. > > On Mon, Dec 5, 2011 at 3:46 PM, Martin Thomson <martin.thomson@gmail.com> wrote: >> On 6 December 2011 07:29, Julian Reschke <julian.reschke@gmx.de> wrote: >>> On 2011-12-05 21:20, James Snell wrote: >>>> Ok... well like I said, I don't have a problem pulling this if it does >>>> overlap. For now, however, until it's clear that something else >>>> adequately covers this requirement, I'll keep it in. >>> >>> Martin? >> >> The 'wait' tag seems perfectly appropriate to me for monitoring >> changes in resource state (aka long -polling). As specified in -04, >> it works, though it's not necessarily clear from the text. >> >> My current thoughts are that you can have a resource with a particular >> state, indicated by an ETag. By using If-None-Match (or one of the >> other conditional headers) and Prefer: wait=x, then you can request >> that the server only provide an update when the resource changes, >> within that interval. It's a new use of the conditional headers, as >> well as a slightly different spin on the wait header, but I think that >> it's workable. >> >> Of course, you could use the 'wait' tag without anything fancy if the >> resource simply had specific logic for long-polling. It seems less >> nice that way. >> >> I might be able to draft a paragraph or two to add if folks are >> amenable to this. >> >> --Martin
Received on Tuesday, 6 December 2011 00:33:13 UTC