Please update SRFI-106
Takashi Kato
(06 Aug 2013 19:39 UTC)
|
Re: Please update SRFI-106
John Cowan
(06 Aug 2013 20:19 UTC)
|
Re: Please update SRFI-106
Takashi Kato
(06 Aug 2013 20:44 UTC)
|
Re: Please update SRFI-106
John Cowan
(06 Aug 2013 21:23 UTC)
|
Re: Please update SRFI-106 Shiro Kawai (07 Aug 2013 08:51 UTC)
|
Re: Please update SRFI-106
Takashi Kato
(07 Aug 2013 19:43 UTC)
|
Re: Please update SRFI-106 Shiro Kawai 07 Aug 2013 08:45 UTC
>From: John Cowan <xxxxxx@mercury.ccil.org> Subject: Re: Please update SRFI-106 Date: Tue, 6 Aug 2013 17:23:28 -0400 > You can use bound UDP sockets with this API, but not unbound ones: > for those you need access to sendto() and recvfrom(). See > <http://trac.sacrideo.us/wg/wiki/DatagramChannelsCowan>. It would be nice to have a socket srfi completed with sendto/recvfrom, but it opens up an issue about how to deal with socket addresses. DatagramChannelsCowan proposal uses host/port pair and just hide the low-level representaion, which is ok. But one of the situations where you want to use UDP is where you want to eliminate comunication overhead, and in such a situation, I don't want sendto to parse host address every time and/or recvfrom to allocate hostname. (E.g. Gauche's socket-recvfrom! allows caller to preallocate sockaddr object to be filled in, guaranteeing no consing.) We can discuss whether to leave such performance hack to each implementation, or how to abstract socket address object. But the current draft looks good as a common factor of existing socket interfaces and will cover the immediate needs of basic socket operations, so I feel it's acceptable to leave sendto/recvfrom to another "Datagram socket" srfi. --shiro