W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: QUIC and WebRTC Comments

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 10 Jan 2018 21:53:48 +0000
Message-ID: <CAJrXDUE+GA1WQzdTkFY8ujufefQOXuWeWXKaY18u4HA8S5QF0Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: public-webrtc@w3.org
On Wed, Jan 10, 2018 at 1:47 PM Martin Thomson <martin.thomson@gmail.com>

> 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
> > 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?
Received on Wednesday, 10 January 2018 21:54:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 January 2018 21:54:28 UTC