Re: QUIC and WebRTC Comments

On Wed, Jan 10, 2018 at 1:47 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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'm not against having standards for QUIC "data channels".  But they can be
implemented in JS.  They don't need to be implemented in the browser.


>
> > 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.)
>

I can write one up for the QUIC WG.  Do you think that would be productive?


>
> > 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).
>

Why not?  What's preventing it from being implementable by JS?