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

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_listen
> 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 Thursday, 21 February 2013 09:23:30 UTC