Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls
From: dls@mentor.cc.purdue.edu (David L Stevens)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: sockets vs. streams
Message-ID: <13644@mentor.cc.purdue.edu>
Date: 5 Sep 90 15:59:33 GMT
References: <13526@mentor.cc.purdue.edu> <9009012315.AA08202@world.std.com>
Organization: PUCC UNIX Group
Lines: 25

In article <9009012315.AA08202@world.std.com>, bzs@WORLD.STD.COM (Barry Shein) writes:
> As to David Stevens questions about file system semantics, what does
> "cd /dev/anydev" mean now? Nothing, you get back "Not a directory".
> In this mythical TCP you might get back something (e.g. some form of
> NFS done this way), or not. I don't see that as a serious problem.

	It's not the same analogy, which was my point. Crispin's example,
which you may not buy into, specifically uses "/"'s below the pseudo-device
boundary so that they become the exception to the syntax-directed pathname
translation that otherwise has the wonderfully dependable rule: "/ separates
directories."
	It's wrong because it's ugly and it doesn't fit with UNIX. Sure,
with a big enough hammer, you can make anything fit, but "/" is the wrong
delimiter. If the syntax doesn't follow the semantics, you've only created
a wart on a once-elegant system.
	As to the rest of your statement, I agree there is too much heat
and I'm not sure why, either. There may very well be a reasonable solution
that maps sockets onto a filesystem, but I see quite a few problems with
the Crispin solution, and (Mr Crispin,) your straw-man arguments, which
you make in your extremely creative interpretation of my article, don't
support your case. To me, anyway. You leave me with the impression, whether
justified or not, that you haven't thought through the details carefully,
and that's where all the mess comes up in the first place.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)