Re: SYN_REPLY

Fully agreed it's more general. I think that unless we go all the way with
ditching SYN_STREAM too (which I disagree with), then I think it's a net
loss (primarily due to more difficulty in grokking the spec) to save a
frame type value and combine SYN_REPLY and HEADERS into one.


On Mon, Feb 25, 2013 at 8:39 PM, Roberto Peon <grmocg@gmail.com> wrote:

> HEADERS can be used for arbitrary other key-value metadata, in
> other-than-HTTP semantic layers so it more general a name than SYN_REPLY.
>
> It is cheap either way, and I don't care either way :)
> -=R
>
>
> On Mon, Feb 25, 2013 at 8:36 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> It's kinda nice when reading the spec to have a symmetric
>> SYN_STREAM&SYN_REPLY. Is there a reason to prefer the HEADERS name over the
>> SYN_REPLY name? One main use case with HEADERS was for server push, but now
>> that we're opting to use a PUSH_PROMISE frame rather than a SYN_STREAM as
>> our "promise", we don't need HEADERS since we'll just send a SYN_STREAM
>> when we need it.
>>
>> How important is supporting stuff like chunked extension headers and http
>> trailers? I guess we need to support it for backwards compatibility reasons
>> with HTTP/1.X? I guess if we need that, then a HEADERS name might be more
>> "general", but it is somewhat hurtful for the common case where all the
>> headers come back in a single reply.
>>
>> If no one has other comments about this, then don't worry about my
>> concerns and move forward anyways. I'm more lamenting the assymetry of
>> SYN_STREAM and HEADERS. I suspect it'll confuse people. Honestly, despite
>> the "wastefulness" of a frame type, maybe it's better for clarity's sake to
>> burn a frame type (they're cheap). I think the code cost is cheap too.
>>
>>
>> On Thu, Feb 21, 2013 at 4:09 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>
>>> Indeed, on re-reading the first message, that is what you're proposing.
>>>
>>> Seems reasonable to me.
>>> -=R
>>>
>>>
>>> On Thu, Feb 21, 2013 at 4:07 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>
>>>>
>>>> > SYN_REPLY doesn't have one, because it doesn't need to declare
>>>>> priority--
>>>>> > the SYN_STREAM already did that, and it is almost always a waste to
>>>>> include
>>>>> > a priority field in SYN_REPLY.
>>>>>
>>>>> Agree.  So what does SYN_REPLY actually do then?
>>>>>
>>>>> It contains a HEADERS block and little else. If you're arguing to
>>>> elide SYN_REPLY given HEADERS, then sure, I can see that-- the frame fields
>>>> are the same now that we've removed the 'in-reply-to' field.
>>>>
>>>> -=R
>>>>
>>>
>>>
>>
>