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?

* 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.

Best regards,
Tomoyuki

[1] https://developer.mozilla.org/en-US/docs/DOM/element.addEventListener#Older_way_to_register_event_listeners
[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 Tuesday, 19 February 2013 01:27:58 UTC