Subject: One to many streams - Use cases

From: Ian Swett <[email-masked]>
Date: Fri, 21 Jul 2017 07:46:39 -0400

One portion of PR#672 <https://github.com/quicwg/base-drafts/pull/672> is
that it introduces one to many streams.

This was asked at the WG, but are there any use cases?  And in particular,
any where the application wouldn't be better off building on top of
unidirectional streams?

One to many streams add a substantial amount of complexity and I'm not sure
anyone has a good API for them.  And if there's no good API, then I doubt
it's a useful abstraction at the transport layer.

Ian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jul 2017 14:01:24 +0200

You might read this as an argument against that design, but here goes anyway...

672 is too complex. The design that I'm looking for here is much
simpler.  A stream can be in reaction to any other stream.  A value of
zero in that field indicates that it is unidirectional, other values
indicate that it is a reaction to another stream.

The consequence of this design is that in order to fulfill your
request, the transport treats receipt of two streams that point to the
same root as an error.  My suggestion is that this be left to
application protocols - that allows them the choice about whether to
make the error a stream error or a connection error.

It's relatively easy to make this a connection error, but that takes
some choice away from applications.  In HTTP, this would obviously be
a connection error either way - there is no reason to do this.

On 21 July 2017 at 13:46, Ian Swett <[email-masked]> wrote:
> One portion of PR#672 is that it introduces one to many streams.
>