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

Hi,

I am not sure if using "tcp:" and "udp:" URI scheme would be much useful
given that you will anyway have to use "tcp:something" in TCPSocket
constructor. and "udp:foo" UDPSocket constructors. That would have been
pretty nice if we were trying to target a generic constructor like "new
Socket('tcp:example.com');". I would have nothing against it though
because it would make the default port handling and things like that
going smoothly in the URI specification.

However, I think the idea of using URI is still interesting and instead
of having methods taking a "address" and a "port" they could just take
an URI and simply use the URL and the port. It makes usage a bit simpler.

If you haven't open an issue regarding this proposal, I think you should.

Cheers,
--
Mounir

On 26/04/13 00:06, Alexandre Morgaut wrote:
> 
> 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)
> 
> 
> 
> 
> 
> 
> 
>  
> 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
> 
> 
>  
>

Received on Thursday, 9 May 2013 15:04:56 UTC