[sysapps/raw socket api]: address + port vs uri

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

This which might be replaced by the recently proposed "app:" uri scheme in the context of packaged app: http://app-uri.sysapps.org/


And of course, the Web Socket API use the "ws:" and "wss:" uri schemes:
- http://www.w3.org/TR/websockets/#dom-websocket

- http://www.w3.org/TR/websockets/#refsWSP

- http://tools.ietf.org/html/rfc6455#section-11.1


It would then looks natural to me to use "tcp:" and "udp:" uri scheme
They could, as "http:", "ws:", "ftp:" and others, integrate the authority part in which can be specified the port number;
http://tools.ietf.org/html/rfc3986#section-3.2


I didn't saw yet "tcp:" uri scheme but "udp:" is listed as a "provisional uri scheme":
http://www.iana.org/assignments/uri-schemes.html

Its basic syntax clearly show the "port" information:

udp://<server>[:<port>]/

A more advanced syntax provide additional informations, including multicast one:

udp://[<localaddress>@]<destination|multicastgroup>[:<port>]

The little issue is that it has been semantically declared for "MPEG Transport Stream over UDP" instead of only "UDP"
http://www.iana.org/assignments/uri-schemes/prov/udp



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.
But if some followed my point, they also think about the recent URL API : http://url.spec.whatwg.org/

- which may be expanded to support them
- or be the basis for a similar API supporting different schemes (URI instead of URL?)

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 means for example that UDPMessageEvent could be a standard MessageEvent instead in which the remote address and port would be specified in the "origin" attribute:
- http://raw-sockets.sysapps.org/#interface-udpmessageevent

- http://www.w3.org/TR/webmessaging/#dom-messageevent-origin


It lets also room of course for "tcps:" and "udps:" uri schemes to handle ssl
(but we still need to think of the "exchange server" use case requiring deferred updateToSSL)








[cid:366be6.png@620fc40a.44aab692]
Alexandre Morgaut
Wakanda Community Manager
Email : Alexandre.Morgaut@4d.com<mailto:Alexandre.Morgaut@4d.com>
Web :   www.4D.com<http://www.4D.com>

4D SAS
60, rue d'Alsace
92110 Clichy - France
Standard :      +33 1 40 87 92 00