This page is part of the web mail archives of SRFI 106 from before July 7th, 2015. The new archives for SRFI 106 contain all messages, not just those from before July 7th, 2015.
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 > socket? > 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. -- _/_/ Takashi Kato E-mail: ktakashi@xxxxxxxxx