Message-Id: <9411182137.AA05713@ulua.hal.com>
To: Mic Bowman <mic+@transarc.com>
Subject: Re: AFS URLs
In-Reply-To: Your message of "Fri, 18 Nov 1994 14:03:49 EST."
<9411181904.AA26430@mocha.bunyip.com>
Date: Fri, 18 Nov 1994 15:37:08 -0600
From: "Daniel W. Connolly" <connolly@hal.com>
In message <9411181904.AA26430@mocha.bunyip.com>, Mic Bowman writes:
>
>> The main reason for not using 'file:' is that it's really already
>> defined for other purposes, and the overloading that you're proposing
>> for 'afs' doesn't work well for sites that might want to use local
>> files but don't run afs. It also doesn't work well for non-Unix
>> systems, does it?
>
>Why is this overloading file? AFS is a file system. AFS users
>don't really care if they are using AFS or NFS. It is the local
>file system. It just happens that the local file system is much
>bigger than the typical NFS. It seems to me that this is precisely
>the thing for which "file" was designed.
Hmmm... I'd say that the local file/ftp overloading of file: was a bad
idea, but using file: for AFS is a fairly reasonable idea (I don't
really understand these passing references to gateways, though.)
I look at the file: URL scheme as having the same semantics as
the MIME local-file external body access type:
7.3.3.3. The "local-file" and "afs" access-types
An access-type of "local-file" indicates that the actual body is
accessible as a file on the local machine. An access-type of "afs"
indicates that the file is accessible via the global AFS file system.
In both cases, only a single parameter is required:
NAME -- The name of the file that contains the actual body data.
The following optional parameter may be used to describe the locality
of reference for the data, that is, the site or sites at which the
file is expected to be visible:
SITE -- A domain specifier for a machine or set of machines that
are known to have access to the data file. Asterisks may be used
for wildcard matching to a part of a domain name, such as
"*.bellcore.com", to indicate a set of machines on which the data
should be directly visible, while a single asterisk may be used to
indicate a file that is expected to be universally available,
e.g., via a global file system.
To me, the distinction between:
file://host.my.org/a/file
and
afs://host.my.org/a/file
is that the file: one does _not_ really have global scope. It's only
guaranteed to work on host.my.org. If I have special knowledge that
host2.my.org's filesystem is the same as host.my.org's filesystem
(because they both use NFS, or AFS, or whatever to mount all the same
files) then it makes sense to try to fopen("/a/file") on host2.my.org.
But if my browser, running ulua.hal.com sees file://host.my.org/a/file,
it really should punt, or at least warn the user "/a/file might not
be the same as what the author indented it to be." Consider, as an
extreme case, file://host.my.org/etc/motd.
On the other hand, afs://host.my.org/a/file _does_ have global scope. But it
is _only_ available to clients that support AFS.
The trick is that most web clients that have AFS support don't even
know it.
On the other hand, there's no harm in having browsers that see
afs://host.my.org/a/file try to
fopen("/host.my.org/a/file") [syntax?]
If there's AFS kernel support and sufficient net connectivity, you
win. Else, you lose.
So in an implementation, the distinction between
file://host.my.org/a/file
and
afs://host.my.org/a/file
is that on seeing file:..., the browser does: fopen("/a/file"),
whereas on seeing afs:, the browser does: fopen("/host.my.org/a/file").
I suppose you could get the same effect by writing:
file:/host.my.org/a/file
Does this make sense?
Dan