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

[Lennart Grahl <[e-mail]>]

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?) [...]