Re: Prefer Draft Feedback

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.

- James

On Mon, Dec 5, 2011 at 3:50 PM, James Snell <> 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 <> wrote:
>> On 6 December 2011 07:29, Julian Reschke <> 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