API Design: LP2PQuicTransport listener

[backkem]

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 API Design: EventHandler vs ReadableStream #30 by turning it into a ReadableStream instead.

[backkem]

Solved by #33.