Re: [Raw Socket API]. New version separating UDP and TCP interfaces

Hi Claes,

> [Claes] So do you think that this ok now?

Ok, at least for AcceptInfo.
I haven't finished checking the other APIs yet.

Regards,
Tomoyuki


(2013/02/24 21:54), Nilsson, Claes1 wrote:
> Hi Tomoyuki,
>
> Please see below.
>
> Best regards
>    Claes
>
>> -----Original Message-----
>> From: Tomoyuki SHIMIZU [mailto:tomoyuki.labs@gmail.com]
>> Sent: den 22 februari 2013 02:21
>> To: public-sysapps@w3.org
>> Subject: Re: [Raw Socket API]. New version separating UDP and TCP
>> interfaces
>>
>> Hi Claes,
>>
>> Thanks again for your further update!
>>
>>> [Claes] Yes, that is correct. I will remove the peerAddress and
>> peerPort attributes from AcceptInfo as they are attributes of the newly
>> created socket object for the accepted socket:
>>
>> Thanks!
>>
>>> Furthermore I see that the type for the socket attribute should be
>> TCPSocket, not RawSocket.
>>
>> Right.
>>
>>>> * As for ReadInfo, RecvFromInfo and AcceptInfo, I would like to know
>>>> how developers can check local address and port actually receiving
>>>> from or connecting with the peer in the callbacks. If using
>>>> 'this.localAddress' for example, I'm afraid that applying bind()[2]
>>>> could prevent the callback functions from checking them.
>>> [Claes] I am not sure that I follow your concern here. The intention
>> is that a successfull bind() will set the values of localAddress and
>> localPort attributes and a successful connect() will set the values of
>> peerAddress and peerPort attributes and accept() will set the values of
>> all attributes. Will the application not be able to access the socket
>> object attributes? If for example the created socket object is
>> "myTCPSocket" wouldn't myTCPSocket.localAddress work? However, the
>> Chrome socket API, http://developer.chrome.com/apps/socket.html, uses a
>> method getInfo() to retrieve attributes of the socket object. Do we
>> need something similar here?
>>
>> Sorry for my confusing comment. I intended NOT bind() in Raw Socket API,
>> but Function.prototype.bind() in JavaScript 1.8.5 and later (ECMAScript
>> 5)[1], which can manually assign another object to 'this'. (Note: This
>> issue would not be a problem when callback functions refer to global
>> variables.)
> [Claes] So do you think that this ok now?
>>
>> Best regards,
>> Tomoyuki
>>
>> [1] https://developer.mozilla.org/en-
>> US/docs/JavaScript/Reference/Global_Objects/Function/bind
>>
>>
>> (2013/02/21 18:22), Nilsson, Claes1 wrote:
>>> Hi again Tomoyuki and thanks for your further comments!
>>>
>>> See my replies inline below.
>>>
>>> Best regards
>>>     Claes
>>>
>>>> -----Original Message-----
>>>> From: Tomoyuki SHIMIZU [mailto:tomoyuki.labs@gmail.com]
>>>> Sent: den 19 februari 2013 02:27
>>>> To: public-sysapps@w3.org
>>>> Subject: Re: [Raw Socket API]. New version separating UDP and TCP
>>>> interfaces
>>>>
>>>> Hi Claes,
>>>>
>>>> Thanks for your update.
>>>>
>>>>> */[Claes] The reason for the current design is that I used the
>>>>> Chrome
>>>> Socket API as starting point but of course I could change the
>>>> structure to be more consistent with other API proposals to SysApps
>>>> or other W3C APIs that uses event handlers if this provides value.
>>>> However, due to the current discussion on DOMRequest I suggest that
>>>> currently no change should be done until we have a resolution on the
>>>> structure of SysAps APIs/*.
>>>>
>>>> Agreed. I have the same concern about that discussion.
>>>>
>>>> AFAIW DOMRequest and DOMFuture are newly proposed for upcoming specs
>>>> (could be related to DOM4 or later). On the other hand,
>>>> addEventListener (DOM 2 Event) and on- event handlers (before DOM 2)
>>>> are current or older standards[1], widely used in many current web
>> apps.
>>>> IMO, for developers' benefit, older, current and newer styles of
>>>> event handler could coexist, however, they should be dependent on
>> SysApps'
>>>> resolution.
>>>>
>>>>> I think it is useful that addresses and port numbers of source and
>>>> destination would be attributes of RawSocket. Such a RawSocket could
>>>> make parameter definitions of callback functions simpler.
>>>>>
>>>>> */[Claes] This information has now been added as attributes of the
>>>> RawSocket interface./*
>>>>
>>>> Thanks a lot. Additional comments below:
>>>>
>>>> * In AcceptInfo for example, peerAddress and peerPort seem to be
>>>> equilavent to socket.peerAddress and socket.peerPort, respectively,
>>>> aren't they?
>>> [Claes] Yes, that is correct. I will remove the peerAddress and
>> peerPort attributes from AcceptInfo as they are attributes of the newly
>> created socket object for the accepted socket: Furthermore I see that
>> the type for the socket attribute should be TCPSocket, not RawSocket.
>>>>
>>>> * As for ReadInfo, RecvFromInfo and AcceptInfo, I would like to know
>>>> how developers can check local address and port actually receiving
>>>> from or connecting with the peer in the callbacks. If using
>>>> 'this.localAddress' for example, I'm afraid that applying bind()[2]
>>>> could prevent the callback functions from checking them.
>>> [Claes] I am not sure that I follow your concern here. The intention
>> is that a successfull bind() will set the values of localAddress and
>> localPort attributes and a successful connect() will set the values of
>> peerAddress and peerPort attributes and accept() will set the values of
>> all attributes. Will the application not be able to access the socket
>> object attributes? If for example the created socket object is
>> "myTCPSocket" wouldn't myTCPSocket.localAddress work? However, the
>> Chrome socket API, http://developer.chrome.com/apps/socket.html, uses a
>> method getInfo() to retrieve attributes of the socket object. Do we
>> need something similar here?
>>>>
>>>> Best regards,
>>>> Tomoyuki
>>>>
>>>> [1] https://developer.mozilla.org/en-
>>>>
>> US/docs/DOM/element.addEventListener#Older_way_to_register_event_list
>>>> en
>>>> ers
>>>> [2] https://developer.mozilla.org/en-
>>>> US/docs/JavaScript/Reference/Global_Objects/Function/bind
>>>>
>>>>
>>>> (2013/02/18 19:29), Nilsson, Claes1 wrote:
>>>>> I have uploaded a new version,
>>>> http://sysapps.github.com/sysapps/proposals/raw-socket/Socket.HTML ,
>>>> based on comments from Michal Mocny and Tomoyuki SHIMIZU. Thanks for
>>>> your support!
>>>>>
>>>>> Michal:
>>>>>
>>>>> * 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] I now have a base RawSocket interface with attributes and
>>>> methods that are common to UDP and TCP and UDPSocket/TCPSocket
>>>> interfaces inheriting from RawSocket that adds methods specific for
>>>> UDP and TCP./*
>>>>>
>>>>> * 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] I have changed the name of the method to 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
>>>> destroyed as well as all resources related to the socket are
>> released.
>>>> This means that destroy() both executes connect() and destroy.
>>>> However, if there are use case for doing disconnect() without
>>>> destroy() I have to revisit this./*
>>>>>
>>>>> * 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] I haven't changed this yet. 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? Do you have a use case
>> for
>>>> using buffer size?/*
>>>>>
>>>>> *//*
>>>>>
>>>>> Tomoyuki:
>>>>>
>>>>> on- style event handlers such as onconnect(), onrecvfrom(), etc.
>>>> would be easier to understand and use for many web developers.
>>>>>
>>>>> Corresponding event definitions, which can be used in
>>>> addEventListener() etc., would be useful, too.
>>>>>
>>>>> */[Claes] The reason for the current design is that I used the
>>>>> Chrome
>>>> Socket API as starting point but of course I could change the
>>>> structure to be more consistent with other API proposals to SysApps
>>>> or other W3C APIs that uses event handlers if this provides value.
>>>> However, due to the current discussion on DOMRequest I suggest that
>>>> currently no change should be done until we have a resolution on the
>>>> structure of SysAps APIs/*.
>>>>>
>>>>> I think it is useful that addresses and port numbers of source and
>>>> destination would be attributes of RawSocket. Such a RawSocket could
>>>> make parameter definitions of callback functions simpler.
>>>>>
>>>>> */[Claes] This information has now been added as attributes of the
>>>> RawSocket interface./*
>>>>>
>>>>> *//*
>>>>>
>>>>> Best regards
>>>>>
>>>>>      Claes*//*
>>>>>
>>>>> *//*
>>>>>
>>>>> *//*
>>>>>
>>>>> *//*
>>>>>
>>>>> cid:3333625383_1036728
>>>>>
>>>>> *Claes Nilsson M.Sc.E.E*
>>>>> Master Engineer, Research
>>>>> Technology Research - Advanced Application Lab
>>>>> *
>>>>> Sony Mobile Communications*
>>>>>     Phone:  +46 10 80 15178
>>>>> Mobile: +46 705 56 68 78
>>>>> Switchboard: +46 10 80 00000
>>>>> 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.
>>>>>
>>>
>

Received on Monday, 25 February 2013 00:46:52 UTC