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

Re: QUIC and WebRTC Comments

From: Lennart Grahl <lennart.grahl@gmail.com>
Date: Wed, 10 Jan 2018 15:21:08 +0100
To: Peter Thatcher <pthatcher@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, public-webrtc@w3.org
Message-ID: <afcab70e-05d2-99b0-30ac-03f5c0c68606@gmail.com>

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?

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

Received on Wednesday, 10 January 2018 14:25:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 January 2018 14:25:56 UTC