Re: QUIC and WebRTC Comments

On Wed, Jan 10, 2018 at 6:21 AM Lennart Grahl <lennart.grahl@gmail.com>
wrote:

>
>
> On 10.01.2018 08:26, Peter Thatcher wrote:
> > On Tue, Jan 9, 2018 at 10:22 PM Martin Thomson <martin.thomson@gmail.com
> >
> > wrote:
> >
> >> On Wed, Jan 10, 2018 at 4:52 PM, Peter Thatcher <pthatcher@google.com>
> >> wrote:
> >>>>
> >>>> Martin wrote:
> >>>>
> >>>> Regarding the API in its current form:
> >>>>
> >>>> Lennart beat me to this by raising an issue, but this is critical.
> >>>> QUIC is a natural fit for the streams API, and not by accident.  It's
> >>>> hard to see why the current API defines its own methods.
> >>>
> >>>
> >>> The API we have come up with is completely compatible with the WHATWG
> >>> streams.  I have written some example code that implements WHATWG
> >>> streams on top of the QUIC streams we proposed, so we're not losing
> anything here.
> >>> I can share the example code if you'd like.
> >>
> >> Maybe I should take some time to explain how the buffering design of
> >> the API can produce a deadlock.  Or you could read the quic@ietf.org
> >> mail that explains it.
> >>
> >>
> > I'll try and take some time to take a look.
> >
> >
> >> 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.
>
> I disagree with this and here's why: One thing that really bothers me is
> how inhomogeneous official JS APIs are. Sometimes I get the feeling that
> one hand doesn't know what the other is doing which makes JS APIs
> painful to work with and yields an error-prone and non-composable API
> surface. Just to give you a few examples:
>
> - Blob vs Uint8Array. Blob has a size property. Uint8Array has a
> byteLength property. And then there's a normal Array which has a length
> property. So, if I want to work with all of them, I need to watch out
> for three different properties.
> - TypedArray vs DataView. TypedArray types have a .set(array[, offset])
> method whereas DataView has .set*(offset, value) methods. Very easy to
> make a mistake here.
> - require vs. import vs. importScripts in WebWorker. Not really a
> typical API surface but worth mentioning.
>
> With RTCQuicStream as it is now we will get yet another API that
> reinvents the wheel from a JS API perspective. I do not believe it's a
> good idea to write a 1:1 API mapping from one language (or
> specification) to another without trying to create a natural and fitting
> API surface for the target language by using existing components where
> possible. Take RTCQuicStream.readInto as one example. Is returning a
> negative number to indicate EOF really state of the art in JS?
>

If you want to quibble about minor things like how to do EOF or Blob vs
Uint8Array or TypedArray vs DataView, that's fine.  I don't really care
about those distinctions.

What I mostly care about is the functionality, while style is secondary.
So if you specific changes to the style while retaining the functionality,
I'm open to that.  In particular, the buffering part of the API is very
hard to get right (be both usable and have all the necessary
functionality), so I wouldn't be surprised if there are improvements we can
make there.   However, I spent a very long time making sure all the use
cases I could come up with are are covered and with good style.


> Look at RTCDataChannel which largely borrows its API from WebSocket.
> Even though not all concepts have worked in the end, it's still very
> similar. Was that a good idea for starters?


Actually, I think RTCDataChannels are a good example of a mistake.  It
would have been better to provide something lower level and let JS
libraries provide the WebSocket-like thing on the top.  That mistake is
precisely one of the reasons I want the QUIC "data channels" to be lower
level.


> From my personal experience
> when I started using data channels for the first time, I can definitely
> say 'yes!' to that. I could basically throw in whatever I've done with
> WebSocket earlier and it just worked - a composable API, thank you very
> much. (Well, it worked until I learned that 16 KiB messages are the
> practical maximum message size, but that's another story and it's one of
> the reasons why I'm here.)
>
> With WHATWG streams, there have been people investing significant amount
> of time to create an API that's composable, has a native feeling and is
> easy to use, and yet efficiently works with low-level I/O primitives. I
> don't understand why one would prefer a hand-rolled API over that.
>

I specifically designed the QUIC stream API that we've come up with to make
it easy to implement WHATWG streams with a small amount of JS on top.  So
if you want WHATWG streams, you can have them.   I don't understand why
that isn't good enough.

And, honestly, I'm not completely sold on the WHATWG streams.  I think it's
fine if you can do them, and as I mentioned I spent a lot of time making
sure that's possible.   But I'm not "sold" on them as the "one new true way
to do everything".  I tend toward simplicity and doing the simplest thing
possible.  And WHATWG streams don't seem to strike me as simple.  And I
don't see a lot of other Web APIs buying into them.   Are there other APIs
(in the W3C) that have, or are you suggesting QUIC streams be the first?



> Still, if you really want to keep the current API... I'm not entirely
> sure it can be built on top of my demo
> (https://github.com/lgrahl/ortc-streams-demo) but if it doesn't... it's
> not like it's written in stone, yet. :)
>
> Cheers
> Lennart
>