Re: [bug-inetutils] plan9 like socket interface

[Alfred M. Szmidt]

   address@hidden (Alfred M. Szmidt) writes:

   > I've been quite annoyed over how one does sockets on unixoid system
   > for sometimes, specially with all the idiosyncrasies of IPv4 vs. IPv6.

   In what way?  If you use getaddrinfo properly, you don't have to care a
   lot about IPv4 or IPv6 differences in my experiences.  There is a lot of
   code in InetUtils that uses old network coding habits though.

As an example take logger, for such a simple utility you have alot of
code just handling parsing of an host name, and setting up a
connection; and this code is duplicated is about all the utilities.

Ideally, all you should care about is "what you send" and "what you
read"; the "where" and "from" should be handled by some wrapper and
all you want to know is where to read/write from/to some "network
descriptor".

getaddrinfo (from gnulib, thank you Simon!) does make things alot
easier, but I was mostly thinking about simplifying the whole socket
handling business, IP address parsing and what not.

   > Plan 9 has a quite nice API that is very much agnostic when it
   > comes to IPv6, IPv4, ICMP, UDP, TCP, ... etc.  Now, I haven't
   > used it at all, and maybe it is not flexible enough for our
   > purpose.  Here is what a basic ping might look like,

   Personally, I prefer POSIX standard here since people are more familiar
   with it.  Further, I would want to know how portably you could implement
   the Plan 9 interface before deciding.  If you can't do it portably
   (i.e., assume POSIX but no more), I think it is a bad idea.

Full agreement, as you say maybe the Plan 9 interface isn't good for
us.  Using any non-standard _system_ API (not just POSIX, since alot
of things we have are based RFC's) is simply a no-go, but this was
more of wrapping the standard APIs (with all their strange cornder
cases) into something we can use to clean things up.

Maybe this can all be solved by cleaning up the old crufy code, which
will be as much work as implementing a new (internal) API...  Not sure
which way is better.