Email list hosting service & mailing list manager

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