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 14:57:41 UTC