While experimenting a bit with the current LP2PQuicTransport API a couple notes came up.
Since the ontransport EventHandler is on LP2PReceiver, this implies only a LP2P receiver side can currently listen for a QuicTransport. On the other hand, allowing a QuicTransport to be constructed from an existing connection doesn't enforce this limitation.
There's a couple ways I can see to amend this:
Let constructing a transport from an existing connection throw an error on the receiving side. However, this would not be easily inferred from the API signature, it would have to be documented.
Remove the constructor over a connection and keep the one-sided setup on LP2PReceiver.
Add ontransport to both LP2PReceiver, LP2PRequester.
Create a separate QuicTransportListener object. Allow both the listener and QuicTransport to be constructed from the LP2PReceiver, LP2PRequester and LP2PConnection. This seems the cleanest but slightly more verbose. Since this means moving the ontransport to the QuicTransportListener, it can also address #30 by turning it into a ReadableStream instead.
backkem
commented
5 months ago
While experimenting a bit with the current
LP2PQuicTransportAPI a couple notes came up.Since the
ontransportEventHandler is onLP2PReceiver, this implies only a LP2P receiver side can currently listen for a QuicTransport. On the other hand, allowing a QuicTransport to be constructed from an existing connection doesn't enforce this limitation.There's a couple ways I can see to amend this:
ontransportto both LP2PReceiver, LP2PRequester.QuicTransportListenerobject. Allow both the listener and QuicTransport to be constructed from the LP2PReceiver, LP2PRequester and LP2PConnection. This seems the cleanest but slightly more verbose. Since this means moving theontransportto theQuicTransportListener, it can also address #30 by turning it into a ReadableStream instead.