[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Basic socket interface
- To: srfi-106@xxxxxxxxxxxxxxxxx
- Subject: Re: Basic socket interface
- From: Takashi Kato <ktakashi@xxxxxxxxx>
- Date: Sun, 07 Oct 2012 11:19:06 +0200
- Delivered-to: srfi-106@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s1024; t=1349601547; bh=cJiKF4GtPHq8CFzFQB1yl/3LyiKTVOQqyThx7VFyM2w=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ymYQii4ktMYchC15WFafIUveMOeDRYcgM59Fc9CV1lotbd9EfFUTgJfNIHaDCxFSa7zbNsqUurX9Zkvpn6BknU/gKrYnvzu/CmE5oQpwcrDQ+NIIFEyRIxK6O/TueryYZA4qHw/cVw6n4JXx4tfzXWn7sJuJFFqW8fur9Y9IoD4=
- In-reply-to: <20121006.103450.975250343633555134.shiro@xxxxxxxx>
- References: <20121006.103450.975250343633555134.shiro@xxxxxxxx>
- User-agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
Sorry I sent the response individually by mistake, here the same comments.
(2012/10/06 22:34), Shiro Kawai wrote:
> I think the author's intention is to describe minimum basic
> interface for the portability, instead of covering every possible
> features. So it's better to be emphasized that to what extent
> the behavior is 'common', e.g.
Yes, the my intention was really 'basic' means if an implementation have
socket interface then it can conform this SRFI. I agree with you. I will
put it on the next version.
> - For optional arguments, what's the default behavior when omitted?
> This must be a bit complicated in this ipv4/ipv6 mixed world.
This is one of the topic I would like to discuss especially between IPv4
and IPv6. Currently we have more IPv4 than IPv6 however I'm not sure if
this will be other way around in 5 years later.
I am thinking, however, it is better to make default behaviour IPv4
because intranet would use it and it can hold compatibility with other
script. (only my expectation). Any idea?
> - What will happen when connection attempt fails, or cannot bind
> I assume most implementations raises an error, but then, it's better
> to be said so.
Yes, error should be raised. I will add it.
The condition type I am a little bit hesitating to add. If it is better
to suggest what to have, I would say '&socket' as a base condition type
and the rest of detail sub conditions are implementation dependent.
> - About call-with-socket: What will happen on socket when PROC returns?
> What will happen on it when PROC does not return?
> (I can guess, but it's better to be explicit).
Yes, I will add it.
FYI, if 'proc' returns then it returns the result of given 'proc' and
socket will be automatically closed. If 'proc' doesn't return then given
socket won't be closed automatically. It's analogy of 'call-with-port'
> - About socket-recv: I assume it returns zero-length bytevector when
> the peer shuts down the connection. It might also be helpful for
> users to say so.
Yes, I will add it. Thank you.