Shall we define transport concept?

[yutakahirano]

Hi, I'm wondering if we want to define concept-transport, like we have concept-request and Request class
in the fetch spec. Such a separation would be good for describing things like #152. Issues like #185, #128, #79, #93 are related.

I'm thinking about something like acf10ee (for #152 and #185; still WIP).

What do people think?

@aboba @jan-ivar

[jan-ivar]

I'm not sure request is the right concept. That's a JS input object to fetch, we have no such input. From your patch, this sounds like the datagram writable's underlying sink. But other specs seem to make due without actually defining the underlying sink/source as concepts, because there's usually a 1-1 higher-level browser object to attach the [[internal slots]] to.

Even fetch does this: "9. Let pullAlgorithm be an action that resumes the ongoing fetch if it is suspended. ... 13. Let stream be the result of creating a ReadableStream with pullAlgorithm set to pullAlgorithm ..."

I would try it without abstractions first, as I think there's only 4 algorithms.

I would model this on https://w3c.github.io/webrtc-insertable-streams/#stream-creation by hanging all our algorithms off of stream creation of the various streams we create.

• For datagrams, there's only one writer and one reader per transport, and once Make transport.datagram a duplex stream? #181 is fixed, the single WritableStream and single ReadableStream would both be created as part of the creation steps of a new transport.datagrams browser object.

• For uni and bi streams, algorithms would be in the the constructors of https://w3c.github.io/webtransport/#outgoingstream and https://w3c.github.io/webtransport/#incomingstream

[yutakahirano]

Makes sense, thank you.