On Fri, Oct 29, 2010 at 3:14 PM, John Cowan <[email protected]> wrote: > On Fri, Oct 29, 2010 at 5:46 PM, Thomas Bushnell, BSG <[email protected]> > 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
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
