RE: [W3C Sys Apps]: New version of Raw Socket API proposal

Hi Michal,

Thanks a lot for your comments!

See my responses below.

Best regards
  Claes

From: Michal Mocny [mailto:mmocny@google.com]
Sent: den 29 januari 2013 18:59
To: Nilsson, Claes1
Cc: public-sysapps@w3.org
Subject: Re: [W3C Sys Apps]: New version of Raw Socket API proposal

Some quick comments:

* Since you switch to constructor usage (great!) why not have two types: TcpSocket and UdpSocket, so that the methods that only apply to one type are not defined?  Also, the constructor RawSocket('tcp') seems less nice than just TcpSocket().
[Claes] This sounds like a good idea. The structure of the Java Socket APIs are like that, i.e. TCP Socket class http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html and datagram socket class, http://docs.oracle.com/javase/6/docs/api/java/net/DatagramSocket.html. So I will consider this change.
* close() replacing disconnect/destroy: The state of the RawSocket after construction but before connect is different than the state after a close() call.  Also, it is not clear if close() should be called with udp sockets that don't issue a connect().  I think that combining the concept of disconnect/destroy should be well thought out first.
[Claes] Maybe it would be clearer to call the method destroy() as after this operation the socket cannot be used again. Regarding udp sockets that don't issue a connect() the intention is that they should be closed/destroyed as well as all resources related to the socket are released.
* recvFrom: if you do not support buffer size, the developer will have to do their own buffer management.  The callback does not need to be called with each datagram received, the payload may be buffered or sliced up.
[Claes] Could we have buffer size optional or nullable meaning that if not provided or null then callback is issued at each received datagram? If buffer size is provided the received datagrams are buffered or sliced up and the callback is issued when buffer size is reached or when nothing more is received (how to detect that?) For both situations I assume that recvFrom must be called again to continue receiving after a callback.
How does the Chrome socket API work here?





-Michal Mocny

On Mon, Jan 28, 2013 at 3:22 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:
Hi,

I have uploaded a new version of the Raw Socket API proposal: http://sysapps.github.com/sysapps/proposals/raw-socket/Socket.HTML

The major changes are:

* Removed  create() and instead defined a constructor for the RawSocket-object.
* Removed  disconnect() and destroy() and defined a method close().
* Added support for server with Listen() och Accept().
* In "Dictionary CreateOptions" added an attribute "useSecureTransport" for ssl/tls and changed " addressReuse" to default False.
* Definied error handling with DOMError. Callback-functions has a nullable attribut "error" of type DOMError. If success then error === null else if error a DOMError-sträng. Error codes still need to be defined.

Comments are welcome.

Best regards
  Claes



[cid:image001.gif@01CDFFFC.B6426B20]

Claes Nilsson M.Sc.E.E
Master Engineer, Research
Technology Research - Advanced Application Lab

Sony Mobile Communications
 Phone:  +46 10 80 15178<tel:%2B46%2010%2080%2015178>
Mobile: +46 705 56 68 78<tel:%2B46%20705%2056%2068%2078>
Switchboard: +46 10 80 00000<tel:%2B46%2010%2080%2000000>
E-Mail: mailto:claes1.nilsson@sonymobile.com<mailto:claes1.nilsson@sonyericsson.com>
Visiting Address; Nya Vattentornet
SE-221 88 LUND,
Sweden
Disclaimer:
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the named recipient(s) and access to this e-mail by anyone else is unauthorized. The views are those of the sender and not necessarily the views of Sony Ericsson and Sony Ericsson accepts no responsibility or liability whatsoever or howsoever arising in connection with this e-mail.Any attachment(s) to this message has been checked for viruses, but please rely on your own virus checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications. If you are not the intended recipient, please inform the sender by replying this transmission and delete the e-mail and any copies of it without disclosing it.