Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
address + port vs uri #17
Looking to provide a Web API friendly version for our Raw Socket API, implemented by most platforms
I'll start with this first thought: "address + port vs uri"
In different places, we have to handle local and remote addresses and ports
The File API works with "blob:" URI scheme: http://www.w3.org/TR/FileAPI/#url
File API: Directories and System evoke a "filesystem:" uri scheme: http://www.w3.org/TR/file-system-api/#widl-Entry-toURL-DOMString
And of course, the Web Socket API use the "ws:" and "wss:" uri schemes:
It would then looks natural to me to use "tcp:" and "udp:" uri schemes
I didn't saw yet "tcp:" uri scheme but "udp:" is listed as a "provisional uri scheme":
Its basic syntax clearly show the "port" information:
One would say it might be easier to set address and port values to specific parameters or properties compared to constructing a text URI and potentially specify a new scheme.
An advantage, while potentially requiring such URI API, would be a simplification of the socket interfaces making them even more similar to the web socket one
It lets also room of course for "tcps:" and "udps:" uri schemes to handle ssl
Example of alternative interfaces with this approach:
origin of type DOMString, readonly
uri of type DOMString, readonly
Before going to the URI community in the IETF and IANA I need to understand the motivations and benefits with the URI appoach. For WebSockets it is obvious that URL-addressing should be used as the WebSocket protocol is a higher level protocol and uses HTTP handshake but for the lower level udp and and tcp APIs a URI approach is not obvious.
If you do this as URL, you have to call it URL, not URI, especially in the API. It seems WebRTC uses a URL for this too: http://dev.w3.org/2011/webrtc/editor/webrtc.html It's not entirely clear to me what a URL offers over distinct host and port though. I guess at the moment we don't expose primitives in http://url.spec.whatwg.org/ yet to parse host and ports, but we could certainly add those.
I proposed it to have this specification more consistent with what have been done in quite all other network related Web APIs. I think one of the reasons behind the choice of using URLs comes from the Web definition itself:
To call an API a Web API, it is probably best to use at least one of those 3 components
Regarding Benefits, I see:
ex: As Data clones are not yet widely supported in Web storages, it is easier to store a url string than a couple of variables ip + port (would have to use either 2 keys, a JSON stringified object, or a string merging them with ":")
Technically, a single Socket constructor may support either web, tcp, and udp sockets, in which case udp specific method may work only if a udp scheme was used. If we don't provide it, I'm pretty sure a lib will do it.
In this email Claes mentioned:
I proposed to also consider future usage of such URLs directly in HTML markup
<pre source="udp://..." ></pre>
could be used to show some log messages as they come (maybe via a dedicated
It would not be a direct advantage for the Raw Socket API, but using TCP/UDP URLs in this API could open such future opportunities.
On Sun, Aug 25, 2013 at 3:16 PM, Alexandre Morgaut
I agree it's fewer properties, but I don't think it's simpler. It just
Generally speaking when using URLs it brings other benefits. For
We don't even support using tcp: and udp: interchangably. Much less
We're not able to reuse either of those APIs here anyway.
If this was possible then I agree that you'd have a stronger case for
See above. Please make a comprehensive proposal for this if this is
RESOLUTION at the Toronto F2F meeting on August 27-2013: close the udp/tcp scheme issue.
Comments raised at the meeting:
So the decision was to close the issue for now. It may later be reopened and then we must reach out to some other group, W3C TAG, IETF.
Few comments hoping it can help
Biggest argument to me would be Web API consistency
Note also that the WHATWG URL spec describe things that can be useful for this spec as:
Other mentioned opportunity included the possibility to reuse such URLs directly from the HTML markup (in the context of privileged apps)
As for a proposal I agree I did only the initial research I feel competent in like research of what exists in other related APIs and what schemes are already registered at IANA
This is to me the least concern
It only means that used with a URL API those fields would be empty
WebRTC mentioned by Anne use 'turn:' and 'stun:' URLs that are also very different