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

Hi,

> I attach a new, even more simplified version, for UDP. 

Looks good to me. Thanks!

>> [Claes] I think that we should assume that The maximum length of 'data'
>> parameter must not exceed the maximum length of one UDP payload.

Agree.

Best regards,
Tomoyuki


On Mar 28, 2013, at 6:04 , "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com> wrote:

> Hi again,
> 
> I attach a new, even more simplified version, for UDP. 
> 
> I will add support for TCP Clients and Servers now but I am not yet sure if this should be a completely separate interface or if we should have one core raw socket API with attributes and methods that are common for UDP and TCP and then inherit this for UDP and TCP interfaces.
> 
> Best regards
>  Claes
> 
>> -----Original Message-----
>> From: Nilsson, Claes1
>> Sent: den 27 mars 2013 12:16
>> To: 'Tomoyuki SHIMIZU'; public-sysapps@w3.org public-sysapps@w3.org
>> Subject: 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>
>>> 
> 
> <index.html>

Received on Friday, 29 March 2013 01:18:53 UTC