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


On 9 mai 2013, at 17:04, Mounir Lamouri wrote:

> Hi,

Thanks for your feedbacks Mounir

> 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.

My concern was not focused in first place on direct usefulness, but on interface uniformity which could provide indirect good impact like:
- learning curve,
- interoperability with other tools
- simplified interface

This is how it currently work with Web Sockets

var socket = new WebSocket('ws://game.example.com:12010/updates');

-> http://www.w3.org/TR/websockets/#dom-websocket-bufferedamount



> 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.

Having a single constructor providing mixed interfaces might be confusing, but it might be easy to provide a createSocket()  tool method which could allow generic code

> 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.

Sure, let see bellow the basic usage I would expect to work via createSocket()

var socket = createSocket(uri);

socket.onopen = function onopen(event) {
    socket.send(data);
}

socket.onmessage = function onmessage(event) {
    // test "event.origin" if required, would be easier via the URL / Location API
    // handle message via "event.data"
}

With the URI approach, createSocket can easily create a tcp, udp, or web socket on a specific port, with or without ssl
All those technical addressing details would be in the URI string (or object if using the WHATWG URL API proposal), and the business code could be more focused on the business logic itself.

This util createSocket() method could accept a fallback URI to use Web Socket when TCP Socket are not available

var socket = createSocket(tcpURI, wsURI);

Technically, we might even expect XHR to have a compatible interface and generate:
- 'open' event when receiving the response status line
- 'message' events when receiving:
        - the response body
        - or response body parts for multipart response body
        - or chunks for chunked response body

We could then have

var socket = createSocket(tcpURI, wsURI, httpURI);

But this last option would be another step in the future to look with Anne and Julian

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

Thanks
I just opened the issue with the content of the first email: https://github.com/sysapps/raw-sockets/issues/17


Regards,

Alexandre





Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut@4d.com
Web :      www.4D.com

Received on Thursday, 9 May 2013 20:37:58 UTC