To simplify the webrtc networking code, and provide a tool for fixing bug 1385030, bug 1421240, and bug 1189055, it would make sense to have a TCP socket implementation that takes an FQDN/port/IP protocol (the destination), and an SSL flag. This implementation would determine whether it should connect via a web-proxy (based on proxy config), do DNS A or AAAA lookups if needed, and then connect to the destination. dom::TCPSocket could be modified to do this stuff, or we could create a new class (perhaps wrapping TCPSocket) that does this stuff. It would also be nice for this API to be usable from any process (and have it automatically do IPC when needed), but that is not strictly necessary. Honza, which approach do you think would be more fruitful; augmenting dom::TCPSocket, or creating something new? On first glance, I am leaning toward augmenting dom::TCPSocket.
Bug 1569183 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
To simplify the webrtc networking code, and provide a tool for fixing bug 1385030, bug 1421240, and bug 1189055, it would make sense to have a TCP socket implementation that takes an FQDN/port/IP protocol (the destination), and an SSL flag. This implementation would determine whether it should connect via a web-proxy (based on proxy config), do DNS A or AAAA lookups if needed, and then connect to the destination. dom::TCPSocket could be modified to do this stuff, or we could create a new class (perhaps wrapping TCPSocket) that does this stuff. It would also be nice for this API to be usable from any process (and have it automatically do IPC when needed), but that is not strictly necessary. It would need to have an IPC wrapper, at least. Honza, which approach do you think would be more fruitful; augmenting dom::TCPSocket, or creating something new? On first glance, I am leaning toward augmenting dom::TCPSocket.