Re: QUIC and WebRTC Comments

On Wed, Jan 10, 2018 at 6:26 PM, Peter Thatcher <pthatcher@google.com> wrote:
> Not exactly.  I'm talking about the possibility of using a feature of QUIC
> that isn't defined yet, but that I hope will be.  If it is, great.  If not,
> oh well.

If I understand that feature (and your mention was the first I had
heard of it, until today when I saw a proposal), it's still a
protocol.

>> More importantly, I would contend that an API designed for future use
>> doesn't need anything other than streams.
>>
>
> If I can build the API we have so far on top of WHATWG streams (which I'm
> not entirely sure we can do) and I can build the WHATWG streams on top of
> the API we have so far (which I'm sure we can do) , I'll take the API we
> have so far.    I think the closer to QUIC that it is, the better.  Let the
> JS build up abstractions from there.

We're going to have to disagree on this point, I think.  There are
always reasons that choosing a proprietary option seems to be a better
choice, but those are almost always trumped by having a single,
uniform way of doing things.  (That's a "why standards" argument that
I'm surprised you don't find persuasive given the venue.)

> I hope the QUIC WG comes up with something built into QUIC.   If so, we can
> expose it in the API for the JS to use.

For that to happen, we would need a proposal.  (And I think one that
is different to the sketchy thing that I just saw.)

> If not and someone comes up with something on top of QUIC, then that thing
> can be implemented in JS.

Probably not.  To my earlier point, if you let JS get at QUIC
barebones, there is nowhere left for you to shim in something that
would allow you to share the connection (aside from multiple
connections, which is a pessimal outcome in my view).

Received on Wednesday, 10 January 2018 21:47:54 UTC