RE: [Raw Sockets API]: Feedback on style requested

Thanks a lot for your valuable comments Tomoyuki!

See my replies inline below.

Claes

> -----Original Message-----
> From: Tomoyuki SHIMIZU [mailto:tomoyuki.labs@gmail.com]
> Sent: den 27 mars 2013 04:02
> To: public-sysapps@w3.org public-sysapps@w3.org
> Subject: Re: [Raw Sockets API]: Feedback on style requested
> 
> Hi Claes,
> 
> +1 to the API style in this new version.
> 
> My comments (not related to API style) below:
> 
> - I wonder if the useSecureTransport attribute in UDPCreateOptions is
> usable for UDPSocket or not, because TLS/SSL is usually used on TCP
> only.
[Claes] Yes, the " useSecureTransport" attribute is applicable for UDP. One example of UDP using a secure transport is is Web RTC using UDP over TLS for secure peer-to-peer communication.
> 
> - As for ISSUE 1, I agree with the necessity of an event handler for
> sending buffer availability. In the case of POSIX socket, if we call
> send() system call when the buffer is full, it would fail with the
> error EAGAIN or EWOULDBLOCK, and the select() system call may be used
> to wait until the buffer becomes available [1].
[Claes] Ok!
> 
> - I wonder if 'processing' readyState is actually useful or not. IMO it
> seems to be almost impossible to watch the 'processing' state; if
> sendUDP() method would simply pass data to the sending buffer, we could
> immediately know whether the data has been buffered or not.
[Claes] One option would be to make sendUDP() a synchronous method that returns true (ok to send more data) or false (buffer full). This would mean that the SocketRequest interface would not be needed for UDP and that the sendUDP() method would be very similar to the send() method in the Mozilla proposal, http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMTCPSocket.idl#29.
> 
> - The maximum length of 'data' parameter in sendUDP() method seems to
> require discussion. When the length exceeds the maximum length of one
> UDP payload, there can be two choices: (a) an error would occur, or (b)
> the data would be separated into segments within the maximum UDP
> payload size. (POSIX socket follows (a); the error EMSGSIZE would
> occur.)
[Claes] I think that we should assume that The maximum length of 'data' parameter must not exceed the maximum length of one UDP payload.
> 
> Best regards,
> Tomoyuki
> 
> [1] http://man7.org/linux/man-pages/man2/send.2.html
> 
> 
> On Mar 26, 2013, at 23:37 , "Nilsson, Claes1"
> <Claes1.Nilsson@sonymobile.com> wrote:
> 
> > Hi,
> >
> > I attach a rewritten simplified version of the sockets API inspired
> by Web Sockets, Mozilla's proposal and other SysApps APIs.
> >
> > Currently this version only supports UDP and the intention is to get
> feedback from the WG on the style of the API. If the WG considers this
> style to be on the right track I will continue with  support for TCP
> Clients and Servers as well.
> >
> > Best regards
> >   Claes
> >
> > Claes Nilsson M.Sc.E.E
> > Master Engineer - Web Research
> > Advanced Application Labs
> >
> > Sony Mobile Communications
> > Tel: +46 705 56 68 78
> > sonymobile.com
> >
> > <image001.jpg>
> >
> > <index.html>
>

Received on Wednesday, 27 March 2013 11:16:35 UTC