Re: [w3ctag/design-reviews] WebTransport (#389)

A few very preliminary comments from spending an hour or two starting to look over the various documents:

From looking at the explainer, it seems like the "Detailed design discussion" and "Alternative designs considered" sections could perhaps be fleshed out a little bit more.  One example of something I'd have liked to learn from those sections that I didn't would be how this proposal differs in scope from the previous `RtcQuicTransport` proposal; I think there are probably a bunch of other big picture things that are in your head, aren't obvious, and would be useful for the TAG to understand while reviewing.

It would likely also be useful for the explainer to explain how this spec relates to the WHATWG [Streams](https://streams.spec.whatwg.org/) specification.

It would also be useful to understand why the spec currently doesn't expose these in workers, and whether there's a future plan to do so.

Is there a section somewhere, either in the explainer or one of the two specs, that explains how the two specs (the one in WICG and the one in IETF) fit together?

-----

A few very detailed comments on bits that I noticed while jumping around to look at some examples of things:

I'd note that the `if (!!chunk)` in one of the examples is a C++-ism and the `!!` is not idiomatic in JS (although not really needed in C++ either).

> receiveDatagrams() may only be called once at a time. If a promised returned from a previous call is still unresolved, the user agent MUST return a new promise rejected with an InvalidStateError. 

This seems a little bit odd, and likely to be a bit of a programming hazard (producing rejections in unexpected ways, depending on timing/races).  Would it make more sense to return an empty sequence?  That said... in the context of understanding why this method is asynchronous -- would it even be guaranteed to be empty?  If it's asynchronous because the datagrams are on their way over from another thread or process... might asking for more not yield more?

Also, it seems like the type of `receiveDatagrams` is slightly wrong, since the prose says that it allows nulls in the result.  It seems like it should be `Promise<Sequence<Uint8Array?>>`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/389#issuecomment-507901719