Re: SYN_REPLY

On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 25 February 2013 20:42, 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.
>
> I'm interested in what you feel SYN_STREAM provides that you can't get
> with HEADERS.
>
> I don't care either way about whether the priority is in the message
> or not.  So, in the interests of saving those few bytes, that's a
> feature that could be retained (or even moved to HEADERS).
>

I'm not completely clear here on the stated proposal, so I'll just
reclarify my position here. I think that the priority should be
communicated in the same frame which starts the stream, whether that frame
be called SYN_STREAM or HEADERS. I'm not sure if it makes sense to continue
including the priority information for followup headers, that may arrive in
a HEADERS frame. I'm leaning towards saying it does not.


>
> The only other thing is the UNIDIRECTIONAL flag.  This flag is
> currently redundant: all streams sent by the client are bidirectional,
> and all streams from the server are unidirectional without exception.
>

I think in the normal HTTP use case, yes. But when you view HTTP/2 as a
transport layer for other protocols, then I think it might be reasonable to
have the server initiate a bidirectional stream. Currently there's no
binding for that in the web platform, but you could imagine it (register an
event handler for server initiated streams, rather than relying on hanging
GETs / client initiated WebSockets). I don't feel strongly here due to not
having a concrete use case.


> As I said in another mail, I'm not sure that SYN_STREAM/SYN_REPLY
> actually help with understanding the spec.  On the contrary, I think
> that they lead to false impressions about how streams start.  They
> imply negotiation, which is far from the case.
>

Intriguing. I did not read the read the earlier email and that was my bad.
I think I have a bias because it's always been called SYN_STREAM and
SYN_REPLY and that's how I conceptualize it. I'm willing to say that my
conceptions on the naming might be very biased and maybe should be
discounted.

In summary, here's my current position:
* the first frame for a stream should include its priority (to be clear, I
don't view the PUSH_PROMISE as belonging to the promised new stream, but to
the associated stream)
* it feels weird to me for subsequent frames on the stream that include the
header name/value block to also include the priority. i don't like the
tight coupling of that.
* i feel less strongly about the naming of SYN_STREAM+SYN_REPLY vs HEADERS,
after what Martin wrote. i fully admit my mental bias here.