James Carlson wrote:
Jeremy Harris writes:
Wandering somewhat further off-topic, I've long held that everything
on a Unix system should be observable, configurable and usable via
the filesystem. With no tool more complex than "ls" and "cat >", if
needed.
On that basis of course, sockets were a mistake.
That sounds to me like the design assumption of something like Plan 9
rather than UNIX.
I'd say it was an initial design principle of both Unix and Plan 9, but
only Plan 9 stuck with its principles. It was an explicitly stated
principle in early descriptions of Unix but it was ignored by various
parties who designed new subsystems along the way, perhaps appropriately
in at least some of the cases. Many networking constructs map very
poorly to named files. I've seen many proposals for filesystem-based
networking APIs and none of them made me think "aha, that's a very
elegant, consistent, and intuitive model for networking!" I'm sure one
can find many long discussions of the topic in the comp.unix.* archives.
It is an admirable goal in general. But it has its problems too. In
the case of DLPI, one of the lessons learned is that it doesn't work
well to embed knowlege of filesystem naming conventions in applications
when those conventions may have to evolve. We are now wrapping a
library interface around what was essentially a filesystem interface
(although because it's STREAMS M_PROTO based it required more than just
read and write) in order to have a bit more abstraction and
implementation flexibility.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
