Re: SYN_REPLY

Interesting that you think that it's a optimization that needs
experimentation.  There's no need to perform experiments to see if
removing a code point has had the desired effect.  When the code point
isn't there, everything is better.

Will seems to think that some explicit indication that this is a
stream start is nice.  I disagree*, but wont fight for this.  I see
the current design as being confused in the way that it communicates
with respect to streams starting and stopping.  This is exacerbated by
the existence of three different header-carrying frame types.

I would prefer to see streams begin when frames are sent on them.
This is how the protocol really works, but SYN_* gives the false
impression that streams have a negotiated open sequence.

--Martin

*Consistency should always be the last argument for doing anything.

On 25 February 2013 20:51, James M Snell <jasnell@gmail.com> wrote:
> "Combining SYN_REPLY and HEADERS" isn't quite the right terminology
> here but I believe there is some optimization that we can get by
> eliminating SYN_REPLY and using SYN_STREAM to signal responses. If the
> outbound SYN_STREAM has the same opaque-id as the inbound SYN_STREAM,
> then it's a reply. That ought to be easy enough to coordinate and
> gives us good consistency with SYN_STREAMS for pushes. That gives us
> the potential option of allowing servers to prioritize response
> traffic.
>
> For right now, however, I'd say it's likely best to leave SYN_REPLY as
> it is and do some experimentation to figure out if this optimization
> really does make sense. We can pull SYN_REPLY out in the next
> iteration.
>
> On Mon, Feb 25, 2013 at 8:42 PM, William Chan (陈智昌)
> <willchan@chromium.org> wrote:
>> 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
>>>>>
>>>>>
>>>>
>>>
>>

Received on Tuesday, 26 February 2013 23:35:57 UTC