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.
Thanks for the long-awaited srfi! 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. - For optional arguments, what's the default behavior when omitted? This must be a bit complicated in this ipv4/ipv6 mixed world. (e.g. how can I write a portable server that accepts both v4 and v6 connections? Some OS allows that I can wait for both on a single socket, while others I need to open one socket for each. I don't think we need to stick to one behavior in srfi-level, but it will help to write portable code if possible variations are explained.) - 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. Whether the type of condition should be specified or not is an open question. If the author's intention is to encode the common state of the current implementations, maybe we don't need to say the condition type, but again, it'll be helpful to describe what kind of conditions is used in existing implementations. - 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). - 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.