Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ENCORE.COM!bzs
From: bzs@ENCORE.COM (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: syntax of remote pathnames?
Message-ID: <8903290327.AA06017@multimax.encore.com>
Date: 29 Mar 89 03:27:38 GMT
References: <8903281410.AA04667@hogg.cc.uoregon.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70


I'm having problems understanding all the baroque (or is that rococo?)
suggestions, let's try starting at the beginning...

A file system syntax (not semantics) is a string describing a point in
a data structure.

Most systems I know of use either arrays (ie. no directories, RT-11),
trees (Unix, MS/DOS) or forests (most DEC OS's, IBM/MVS, VM/CMS is a
forest of arrays I guess, degenerate case.)

I call them forests rather than funny-rooted trees since I don't
believe, given some path like [000000,000000]<foo.bar>stuff.xxx you
can add syntax to walk back up and down a different path a la Unix's
/foo/bar/../../down/down which is equvalent (well, usually, ahem) to
/down/down (ahh, symlinks...but I doubt you'll solve that problem here
nor even suggest trying.)

The question is how much SEMANTICS you want to build into the syntax.

Should the SYNTAX reflect that the first step off the root is a
username? Or is it sufficient to just let the remote O/S worry about
that translation? Thus something like <BZS.STUFF>ABC.DEF can be
represented as /bzs/stuff/abc.def and be easily interpreted.

That's really the major difference between Unix syntax and other OS's
being mentioned, Unix isn't using punctuation characters to indicate
semantics.

Now, I will point out that (having written a program to go between
TOPS-20 and Unix paths) there are potential ambiguities, although they
mostly fall into the "would someone really *do* that?" category, for
example, does:

	/foo/bar/baz.xxx

on a TWENEX system become:

	foo:<bar>baz.xxx

or

	<foo.bar>baz.xxx

?

They can both exist simultaneously and describe different files. The
same can be true for VMS and other OS's that have this sort of thing
for devices and logical names. Pity.

Is it sufficient to suggest that people avoid creating that potential
ambiguity if they want to be accessible (or at least only interpret
paths one way? I could imagine a local system optionally interpreting
/foo:/bar/baz.xxx as a device/logical name and /foo/bar/baz always as
<foo.bar>baz.xxx, not pretty.

I suppose the same can be said for hostnames (eg. /foo/bar, is foo a
local directory or a remote host?) It's been "solved" in every
conceivable way (//foo/bar is remote, /../foo/bar is remote, only
/remote/foo/bar is remote, etc etc.)

Of course, whatever we do won't fit the next thing coming around the
corner (I dunno, free-association concept array-driven file systems
with prescient error recovery.)

Anyhow, I think Keep It Simple might be a good plan for this one,
trying to cover every unusual case usually makes for a bad design
("hard cases make bad law".)

	-Barry Shein, Software Tool & Die