Re: SYN_REPLY

Opcode or flags, it matters not.  It depends on where you want to
spend your bit (or part thereof).

On 27 February 2013 10:45, Roberto Peon <grmocg@gmail.com> wrote:
> The we're wasting bytes on responses. Bleh. Worse, now we can't simply
> examine the length field to figure out what to do. Double-eww.
> In any case, spending a bit in the flags, is far more costly than spending
> the fractional bit out of the opcode space, which is what is done today!
>
> Something I could go with, given the previous change would be to also change
> the name of SYN_STREAM to HEADERS_WITH_PRIO
> and leave HEADERS as it is.
>
> How does that sound?
>
>
> -=R
>
>
> On Wed, Feb 27, 2013 at 10:20 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 26 February 2013 20:16, Roberto Peon <grmocg@gmail.com> wrote:
>> > Taking the priority out of SYN_STREAM would only bloat things on the
>> > wire,
>> > since the client will always want to state priority for a new stream. I
>> > don't support removing priority from SYN_STREAM.
>>
>> What if HEADERS contained priority?  Is your objection to removing
>> priority from SYN_STREAM, or removing priority from the first frame in
>> the stream.
>>
>> Here's a more concrete proposal, albeit slightly radical.
>>
>> Remove SYN_STREAM and SYN_REPLY.
>> Have stream-level flags that appear in ALL messages.
>>  1. last frame in stream (the existing FIN bit)
>>  2. stream priority (a new one)
>> The 'stream priority' flag indicates that the first 4 bytes of the
>> frame payload includes a priority.  This should (or SHOULD) be set on
>> the first frame of any stream.
>>
>> Then a typical stream looks like:
>>  - a HEADERS frame with the 'stream priority' flag set, plus a priority
>>  - a bunch of data frames
>>  - maybe some other frames
>
>

Received on Wednesday, 27 February 2013 19:07:54 UTC