RE: RE : [sysapps/raw socket api]: New version based on Madrid meeting comments and comments from Ke-Fong Lin

Hi Jonas,

See inline below.

Claes

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: den 25 april 2013 07:40
> To: Ke-Fong Lin
> Cc: Ekberg, Björn; public-sysapps@w3.org; Nilsson, Claes1; Edenbrandt,
> Anders; Isberg, Anders; Falk, Mattias
> Subject: Re: RE : [sysapps/raw socket api]: New version based on Madrid
> meeting comments and comments from Ke-Fong Lin
> 
> On Apr 23, 2013 12:39 PM, "Ke-Fong Lin" <ke-fong.lin@4d.com> wrote:
> >
> > Hi Jonas,
> >
> > > It's still not clear to me how to use the localAddress/localPort
> arguments for TCPSocket and UDPSocket.
> > > What are the use cases for these options?
> >
> > Local address is needed to select which network interface to use. On
> mobile device, that would be WIFI, 3G, Bluetooth.
> 
> Yup. So the question is what's the use case for, on a client side
> device, setting up a socket connection specifically from wifi, 3G or
> Bluetooth rather than the "default" connection?
[Claes] All socket APIs I have seen provide the possibility to define the local address. I know that this is a bad answer and will come back with Use Case examples.
> 
> > >What does the "addressReuse" option do when constructing a
> TCPSocket? What is the use case?
> >
> > Re-use option is very important for UDP, this allows several
> applications to receive data from a multicast group (to use Bonjour for
> example).
> > But yes, you're right. It makes no sense for TCP sockets (streaming
> protocol). I'm not even sure you could do a setsockopt() on a TCP
> socket.
> > TCPSocket shouldn't have addressReuse.
[Claes] Removed in hen next version.
> 
> If it's only useful for UDP multicast, should it be part of
> joinMulticastGroup instead of the constructor? Sorry, I don't know UDP
> multicasting at all so I'll have to defer to others who do.
[Claes] It was my original proposal to have it in the constructor but the feedback was that it was more visible for developers to have separate methods for joining and leaving multicast groups. If there are use cases for belonging to several multicast groups and for continue to use a socket that previously was belonging to a multicast group we must have separate methods for joining and leaving multicast groups. If we don't need to support these use cases I think that we should just have an optional field in the UDPOptions dictionary stating multicast address. Ke-Fong WDYT?
> 
> > >There doesn't appear to be a way to upgrade an existing TCPSocket
> connection to TLS. Is that something you're still planning on adding?
> >
> > Yes, I'm working on it with Claes.
> 
> Great!
> 
> > >Feedback [1] from our team was that for TCPSocketServer "accept" is
> a better name than "connection" since "connection" was unclear if it
> meant "connecting" or "connected". One option is also simply "connect"
> since that's what's used by Web Workers [2].
> >
> > "accept" will definitely ring a bell for those used to Berkeley
> socket
> > accept() function :) I've no strong opinion regarding naming but yes,
> "onconnect" would be a great name as it is indeed used by SharedWorker
> (web workers).
> 
> Cool, I think "connect" gets my vote then. I'll check with others at
> mozilla and let you know the outcome.
[Claes] "connect" is used in the next version.
> 
> / Jonas

Received on Thursday, 25 April 2013 12:30:48 UTC