On Fri, Oct 29, 2010 at 5:46 PM, Thomas Bushnell, BSG <tb-pPc1tc5p79CsTnJN9+BGXg@public.gmane.org> wrote:

> I don't know what "this" refers to in your first sentence. It seems that it
> refers exactly to my worry that you'll start redesigning what a good
> networking interface looks like. Can you PLEASE not try to be "more
> convenient", and instead focus on clear and transparent mappings to the
> extremely well-understood functions that Posix provides?

I'm not an autonomous implementation designer; I am the servant of the
WG, which voted "yes" on "simple Posix", "TCP", and "UDP" and "no" on
"full Posix" and "full sockets".  Feel free to propose an alternative
that satisfies these requirements.

> When I use datagram-channel-receive-from, what datatype is the host
> returned? A string? A dotted quad notation? Does it do a reverse name
> lookup? What if it fails?

The implementation is free to provide whatever string it likes; in
particular, there is no guarantee that the implementation provides
DNS.

> We're supposed to guess what the PORT argument is, which is annoying given
> that there are both numeric names and string names for ports. Can I pass a
> string and get magical transformation from getservent? What if the string is
> a series of digits and there is a service with those digits defined as a
> symbolic name?

I've added: ''Port'' may be an integer or a string; the meaning of a
string is implementation-dependent.

> Can you please think about either specifying some rules-of-thumb with
> examples for Posix bindings, or let OS designers design operating systems,
> and stick to programming languages?
]
I personally would have been happier just to provide all 1200
interfaces exactly as-is, with type mapping and somewhat more
Scheme-like names, but the WG voted otherwise.  That means more work
for me.

> To tighten up your UDP interface, you need a datatype for addresses, one for
> IPv4 and a different one for IPv6. You need a hostname translation function
> which is not bundled magically into everything else.

Some people need these things, but others don't.

> What is "datagram-channel-interface" supposed to return? Is there some
> "interface" datatype? Or a string?

As specified, an interface in this API is a string whose content is
implementation-defined.

> What if the channel receives datagrams on
> two of my host's five interfaces?

I don't see how that's possible: if a socket is bound to a particular
interface and port, trying to bind it again returns EINVAL.

> Or all of them?

Datagram-channel-interface now returns #t in that case, and
make-datagram-channel now accepts #t.

> What does
> "datagram-channel-connected-host" return? (Does it return whatever was
> passed at connect time, or does it return the value of getpeername, or does
> it return a reverse lookup of the value of getpeername, or does it return a
> canonicalized version of what was passed at connect time?)

Implementation-dependent.

> As it sits, this is a disaster, and is exactly why I expressed my hope that
> you would not adopt this usual disastrous strategy. I understand that Posix
> is a lot of work, but better to say we're not up to it than to do the usual
> half-baked thing.

We (that is, WG2) have said we're not up to it, while still calling
for something else.