Not allowing browser based clients is a feature 😈

I kid.. sort of. There isn't any reason browsers can't be extended to support quic etc.

I think you kinda want to be connection type agnostic. There are connections you'd prefer (quic) or connections you'd settle for (tcp, Bluetooth)

The nice thing is that you don't have to develop them all at once. You just pick the easiest to implement and make an algorithm that "chooses" ```return ConnectionType::quic``` then add types after it works at all and as demand develops.

Reply to this note

Please Login to reply.

Discussion

i'm not sure there is any practical use for bypassing IP on such things as bluetooth, when most bluetooth devices of any recent vintage are capable of doing it. i mean, it's just a PTP connection like a USB serial bus at the level you usually would use it for this, but PAN is available so why complicate things by using a different flow control protocol (and that's a bit of a nightmare in itself, it's why QUIC still mostly follows what TCP does).

of course, being that it's a point to point connection you can just rely on the hardware based flow control for a duplex connection, or you can implement RTS/CTS in your protocol but ... just why not use TCP/IP when you can