Re: [Webtransport] Does WebTransport need a reliable, in-order message abstraction?

[Bernard Aboba <[e-mail]>]

Thanks, Lennart.

"And I want to emphasize again on the naming in the API. So far, these
are all byte steams we're talking about in the WebTransport API but when
adding "message" streams, this isn't clear any more. To quote myself in
above linked issue:

> [...] I think it makes sense to incorporate the type of stream into the
interface in general to avoid confusion in a dynamically typed language
(what kind of stream is this? a stream of bananas?) [...]"

[BA] This problem exists now in the API document, even without support for
messages.

For example, receiveStreams() returns a ReadableStream of receiveStreams;
receiveBidirectionalStreams() returns a ReadableStream of
BidirectionalStreams; readDatagrams() returns a ReadableStream of
Uint8Arrays.  Yet the WebIDL just says "ReadableStream", with no indication
of the kind of stream returned.

On Mon, Jul 27, 2020 at 1:16 AM Lennart Grahl <[e-mail]>
wrote:

>
>
> On 26/07/2020 02:08, Bernard Aboba wrote:
> > Alan said:
> >
> >> Is replacing WebSockets with WebTransport one of our goals?  If so, I
> think we need to address the gap by adding this abstraction.  If not, we
> should explicitly mention that this abstraction doesn’t exist, and instruct
> developers to use WebSocket instead.
> >
> > [BA] Thanks for bringing this up.
> >
> > When we first started on what would become the RTCQuicTransport API, the
> goal was to support all the transport modes of the RTCDataChannel API,
> which was modelled after WebSockets.
> >
> > However, we realized that this required design of a framing protocol on
> top of QUIC reliable streams. After verifying that a simple framing
> protocol was implementable as a JS library on top of the RTCQuicTransport
> prototype, providing many of the services of RTCDataChannel, the “proof of
> concept” was considered done and since then not much has happened.
> >
> > This is a good example of how things can fall between the cracks of
> protocol design and API design. “Assume we have a framing protocol designed
> in IETF....”
>
> Perhaps a clearly defined framing protocol for WebTransport on top of
> those protocols that need it is not a bad idea if it's simple and easily
> negotiable. But beyond that, I urge to always think about the
> entry-barrier for non-web implementations before adding more protocols.
> Because that was one of the top arguments when it came to why supporting
> data channels and SCTP in non-web implementations is a problem.
>
> But back to the "message" feature: I did make a proposal on that to make
> the API future-proof for message streams (i.e. stream of byte stream):
> https://github.com/WICG/web-transport/issues/49
> If we do have a framing protocol, then it can be easily combined with
> the API proposal.
>
> And I want to emphasize again on the naming in the API. So far, these
> are all byte steams we're talking about in the WebTransport API but when
> adding "message" streams, this isn't clear any more. To quote myself in
> above linked issue:
>
> > [...] I think it makes sense to incorporate the type of stream into the
> interface in general to avoid confusion in a dynamically typed language
> (what kind of stream is this? a stream of bananas?) [...]
>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>