RE: [Raw Socket API] Basic Compatibility with Web Socket API

Hi again,

Thanks for providing me with the information in your mail.

As you might have seen I submitted to the SysApps mailing list a version of the SysApps socket API, currently supporting UDP only, to get early feedback on the design of the API. My intention is then to continue with TCP and then see which attributes and methods that can be included a "core raw socket" interface from which UDP and TCP interfaces can inherit. 

I am happy for your comments on the proposal I sent today.

Best regards
 Claes


> -----Original Message-----
> From: Alexandre Morgaut [mailto:Alexandre.Morgaut@4d.com]
> Sent: den 26 mars 2013 15:58
> To: Nilsson, Claes1
> Cc: public-sysapps@w3.org
> Subject: Re: [Raw Socket API] Basic Compatibility with Web Socket API
> 
> 
> Hi Claes,
> 
> and thanks for your answer
> 
> > However, based on comments from the WG I am currently in the process
> of rewriting the API to simply it and create a more "webish" API of a
> style similar to other SysApps APIs. So I am looking for example at Web
> Sockets and socket.io. I plan to submit the new proposal during the
> next week.
> 
> Socket.io is a framework based on the node.js socket API which is not
> bad A difference to have in mind when looking at node.js APIs is that
> W3C ones are meant to implement EventTarget interface while node is
> using its proprietary EventEmitter one Webish should not mean losing
> low level features but at least follow the way events are usually
> managed and objects are usually structured in Web APIs
> 
> The Web Socket API has similarities with specifications like Web
> Workers (onmessage, onerror) or XMLHttpRequest level 2 (readyState,
> send()) It is important to consider RawSocket as based on EventTarget
> like all the ones I mentioned, and also to support as them new objects
> like Blob or ArrayBuffer
> 
> > However, I am not clear on if you propose that support for TCP and
> UDP should be added as a part of the Web Sockets API? I am not sure on
> this. The Raw Socket API is a proposal for the secure W3C web system
> applications runtime, while Web Sockets is available in the normal
> browser context. So the security environments are different.
> 
> That's not what I meant, I was talking about the exposed interfaces.
> Let me be more clear
> 
> Currently, the Web Socket Interface looks like that (subset)
> 
> [Constructor(DOMString url, optional (DOMString or DOMString[])
> protocols)] interface WebSocket : EventTarget {
>   // ready state
>   const unsigned short CONNECTING = 0;
>   const unsigned short OPEN = 1;
>   const unsigned short CLOSING = 2;
>   const unsigned short CLOSED = 3;
>   readonly attribute unsigned short readyState;
>   readonly attribute unsigned long bufferedAmount;
> 
>   // networking
>            attribute EventHandler onopen;
>            attribute EventHandler onerror;
>            attribute EventHandler onclose;
>   readonly attribute DOMString extensions;
>   readonly attribute DOMString protocol;
>   void close([Clamp] optional unsigned short code, optional DOMString
> reason);
> 
>   // messaging
>            attribute EventHandler onmessage;
>            attribute DOMString binaryType;
>   void send(DOMString data);
>   void send(Blob data);
>   void send(ArrayBuffer data);
>   void send(ArrayBufferView data);
> };
> 
> I would first provide a similar Raw Socket interface, or maybe Core
> Socket, or Socket might be more adapted, with anything that might be
> also applicable to TCP and UDP Sockets
> 
> interface Socket : EventTarget {
>   // ready state
>   const unsigned short CONNECTING = 0;
>   const unsigned short OPEN = 1;
>   const unsigned short CLOSING = 2;
>   const unsigned short CLOSED = 3;
>   readonly attribute unsigned short readyState;
>   readonly attribute unsigned long bufferedAmount;
> 
>   // networking
>            attribute EventHandler onopen;
>            attribute EventHandler onerror;
>            attribute EventHandler onclose;
>   void close([Clamp] optional unsigned short code, optional DOMString
> reason);
> 
>   // messaging
>            attribute EventHandler onmessage;
>            attribute DOMString binaryType;
>   void send(DOMString data);
>   void send(Blob data);
>   void send(ArrayBuffer data);
>   void send(ArrayBufferView data);
> };
> 
> It might be defined in a specific Core Socket W3C Recommendation
> 
> Then Web, UDP, and TCP Sockets could all use a compliant API while
> still providing their own constructor, specific states, events and
> potential properties and methods
> 
> ex:
> 
> [Constructor(DOMString url, optional (DOMString or DOMString[])
> protocols)] interface WebSocket : Socket {
>   // networking
>   readonly attribute DOMString extensions;
>   readonly attribute DOMString protocol; };
> 
> we might still have a RawSocket if required
> 
> interface RawSocket: Socket {
> 
>     readonly    attribute CreateOptions   options;
>     readonly    attribute DOMString?      peerAddress;
>     readonly    attribute unsigned short? peerPort;
>     readonly    attribute DOMString?      localAddress;
>     readonly    attribute unsigned short? localPort;
> 
> };
> 
> But at least WebSocket, UDPSocket, and TCPSocket could all inherit from
> a shared Socket interface (itself implementing EventTarget) It still
> let the possibility to redefine the internal algorithms managing
> inherited properties / methods by overriding them
> 
> Note that I'm not exactly a socket experts, I'm more API design focused,
> and heavy JS user.
> Other references you might have a look to are:
> - the CommonJS proposed APIs: http://wiki.commonjs.org/wiki/Sockets

> - the W3C Stream API working draft: http://www.w3.org/TR/streams-api/

>         -> it is currently being discussed by the XMLHttpRequest team
> 
> 
> > I suggest that we can look at this again when I have completed the
> new Raw Socket API proposal, which will have a style more similar to
> Web Sockets.
> 
> I will probably come to the first F2F Meeting, at least for the first
> day.
> I'll also ask Ke-fong, the developer who implemented node sockets, Web
> Workers, Web Storage and many other API on our platform, if he can also
> come.
> 
> 
> 
> 
> 
> 
> 
> 
> 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 Tuesday, 26 March 2013 17:29:14 UTC