Replace sendDatagrams()/receiveDatagrams() methods with attributes?

[pthatcherg]

Was there as good reason for having them be methods? I can't remember any good reason. It might be nice to match WebSocketConnection which has .readable and .writable.

But in that case we might want .datagrams.readable and .datagrams.writable instead of .receivedDatagrams and .datagramsToSend (or similar).

[ricea]

Currently it appears that the transport will ignore any incoming datagrams until receiveDatagrams() is called. That would change if you replaced it with an attribute. However, it's not clear this facility is useful anyway.

[Jxck]

it seems natural that sendXX() has xx as argument. in this case sendDatagram(datagram) and also for receiveX() returns x so datagram = receiveDatagram()

but current spec, sendDatagram() and receiveDatagras() returns stream.

interface mixin DatagramTransport {
    readonly attribute unsigned short maxDatagramSize;
    WritableStream sendDatagrams();
    ReadableStream receiveDatagrams();
};

if thease behave like a getter or creator, their name should be getSomething() or createSomething() which returns something.

[yutakahirano]

Currently it appears that the transport will ignore any incoming datagrams until receiveDatagrams() is called. That would change if you replaced it with an attribute. However, it's not clear this facility is useful anyway.

Is this still correct? Currently receiveDtagarams() just returns the value of the corresponding internal slot.

Reg: naming how about readableDatagarams and writableDatagarms? I prefer attributes to methods too.

[vasilvv]

I think readableDatagarams and writableDatagarms is nice because it would make it consistent with how the streams have readable and writable.

[aboba]

@pthatcherg sendDatagrams()/receiveDatagrams() predated the switch to WHATWG Streams, and they no longer make sense. Better alignment between WebSocketStreams API and WebTransport (particularly if WebSocketStreams will also support QUIC datagrams) is also a good thing.