Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!SAPSUCKER.SCRC.SYMBOLICS.COM!Margulies
From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Need information on NFS
Message-ID: <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: Thu, 25-Dec-86 19:52:00 EST
Article-I.D.: REDWING.861225195214.5.MARGULIES
Posted: Thu Dec 25 19:52:00 1986
Date-Received: Fri, 26-Dec-86 02:37:47 EST
References: <8612250637.AA05517@seismo.CSS.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 90
Approved: tcp-ip@sri-nic.arpa


    Date: Thu, 25 Dec 86 17:26:30 EST
    From: munnari!kre@seismo.CSS.GOV (Robert Elz)

    In <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM>
    sned@PEGASUS.SCRC.Symbolics.COM wrote a lot of nonsense,
    followed by one seemingly correct statement...

I'll leave it to steve to comment on the ad hominem nature of this
little flame, save to point out that it is offensive in the extreme.
Too bad we don't have politeness police.  Slander and libel do exist,
and electronic mail is no license for them.  

I'll concentrate on technical aspects.  However, I will warn Mr. Elz of
this: Steve worked on UN*X for quite a while in his career, and is
eminently qualified to comment.

    > As I see it, the problem is really the lack
    > of support for anything but UN*X filesystem syntax in UN*X.  

    Since Unix filename syntax is a sequence of chars terminated
    by a null (some systems have a maximum length, generally not
    less than about 1024 bytes), its hard to see how this is much
    of a problem.

Consider TOPS-20 directory structure, VM/CMS mini-disks, file system
that permit "/" characters in their filenames, or especially file
systems (like VMS and VM/CMS) that have structured (non-byte stream)
files.  None of them map very quietly into a hierarchical set of
directories separated by "/" characters, and there are more and harder
where they came from.  This is my-file-system-centrism.  Why should a
workstation impose a single model of a file system on all of the
machines it talks to over the network? If I am a workstation users, and
a user of a VMS system sends me mail with a pathname in it, why is it
good that I have to know how to translate it into UN*X ese?  The only
good that I know is that it allows existing UN*X applications, born and
bred in a homogeneous environment, to access files on foreign systems.

I'm not opposed to this.  Steve isn't opposed to this.  Symbolics isn't
opposed to this.  We just note that it imposes some limitations, like
the ones reported by Kasdan.

    > By the way, it's interesting that Lisp Machines, which were designed
    > from the beginning to be used as workstations on a network, adopted the
    > pathname syntax of host:string-for-host for 'open'.  UN*X, which was
    > designed as a self-contained system, has to indirectly chop a local
    > pathname, in UN*X pathname syntax, into host and string-for-host via
    > Special Files and Mount Tables.

    What a load of rubbish.  There have been mny RFS's for Unix at various
    times.  Many early ones adopted some form of "host:string" syntax
    for remote file names, they ALL died (or have been forgotten), because
    that's a REVOLTING method for naming remote files.  That means that
    someone has to know that the files is remote to build that filename,
    and what's worse has to know which host the file lives on.

    Unix implementations don't use mount tables, etc, because that's the only
    way it can be done, or even because its the easiest way it can be done.
    Just the opposite, its MUCH easier on unix to implement a "host:string"
    syntax - an average unix kernel programmer could do one of those (clients)
    (given existing network code) in an easy afternoon.   The mount table
    mechanism is used because it gives the right semantics - host names aren't
    built as a part of the syntax of a filename, they're derived by a level of
    indirection that makes it easy to alter the configuration (you can move
    local files to a remote host without having to change any uses of the
    filenames at all).

This paragraph neatly details my point above: mapping everything to UN*X
syntax is a lot easier on UN*X applications than changing them all to
handle a pathname representation designed to facilitate operations in a
heterogeneous environment.  As it happens, the Symbolics environment
represents pathnames and file system operations in a way that is
optimized to heterogeneous environments.  That was a design goal of
ours, it wasn't of UN*X.

    I'm not going to comment on Lisp machines, as I've never used one.
    From all reports they have a lot of nice attributes, but if Symbolics
    standard of employees is confined to "we're right, nothing else comes
    close" parrots then I don't have much hope for their continued success.

Mr. Elz, please note the history of this conversation.  Someone from
DEC sent mail criticizing NFS for, in a manner of speaking,
UN*X-centrism.  Steve \DEFENDED/ NFS, pointing out that the problem was
merely the small funnel of the pathname syntax (and the lack of
semantics for structured files), and not a fundamental flaw in the
protocol as compared to NFILE.  I hardly call that corporate chauvinism.
If you are going to run about tossing tomatoes like that one, best to be
sure you read your from lines.

  Benson I. Margulies