> I've really not dug in deep into 9P2000 to really appreciate why this is
> better yet I guess.
this is hardly exhaustive, but amongst other things,
import $cpu /net
is rather more tedious in socket land. another variant:
import -a $cpu /net
to extend my machine's protocol set by those of $cpu, so that
i use my protocols when i can, but fall back to $cpu's when needed.
also, each type of socket has its own equivalent to sockaddr_in, so
that socket programs are often confined to a particular type of
network. by contrast, plan 9's telnet can be used (and has been used)
across many network types, because dial is just an encapsulation of a
little dance that culminates in
opening a file with a conventional name (clone)
writing a string with a conventional form into that file "connect
address"
where the key thing is that "address" is a string, thus easily handled within a
program
and conveyed between programs without knowledge of its meaning, but the string's
final recipient interprets it. thus, in plan 9, ndb/cs translates
human-readable strings
into little recipes of the form ``open this file, and write this string into
it''; the essential
level of indirection is trivial to add (but not trivial to invent--it took some
time).
the low-level addresses thus pass transparently through the application.
by contrast, i know one project that needed to switch networks transparently,
and with sockets, it was hard. even replacing the library was not enough,
because the new addresses were bigger than could fit in the sockaddr_in
of the time, and so some amazing hacks were employed to work round that.
