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

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 Sunday, 24 February 2013 12:54:36 UTC