Re: [Scheme-reports] Scheme-reports Digest, Vol 10, Issue 1

On Fri, Oct 29, 2010 at 5:46 PM, Thomas Bushnell, BSG <tb@x> 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.

I recognize this isn't all up to you, and I apologize for sounding differently.

> 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.

What is the point of that? If no portable program could ever use a string, then say it's an integer, and an implementation is free to extend it as it pleases.

> 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.

How about providing the interfaces which are implied by UDP and TCP, but not the rest? I think that's a sensible way to meet the WG's rather difficult decisions.

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

This is exactly the reason that people trot out for call/ec and making tail call optimization optional. :)

> 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.

Then drop the function. No portable program could do anything with its return value except note that string? returns #t. If your intention is that in a "normal" system it might return something like "eth0", then can you please provide a sample implementation? It's harder than you think in Unix.

> 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.

Sockets are not bound to interfaces, they are bound to addresses. If there is no implementation-independent way to specify an interface, then I'm not sure why the argument is there at all, since no portable program could ever use it.

> 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.

Then drop it, because no portable program could ever use it. (For anything, since not even the type is specified.)

> 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.

Sorry, "not up to it" means, "we're not up to providing a networking interface", not "we're not up to providing a good one, so we'll provide a bad one instead."

Thomas