Message-Id: <9411161957.AA10525@mocha.bunyip.com>
To: masinter@parc.xerox.com, uri@bunyip.com
Subject: Re: ANNOUNCEMENT: Free AFS software licenses
Date: Wed, 16 Nov 1994 14:56:39 -0500 (EST)
From: Mic Bowman <mic+@transarc.com>
Larry,
I'd like to address the two issues that you bring up in your
note. The first is that our work leverages off the ambiguity in the
implementation of the 'file' scheme.
I plead guilty to improper use of file:... in the announcement. Users
without our URL translation library need to get the software using FTP
or---those with AFS---by hacking on the file URL to remove the hostname.
However, the translation library itself FORCES all 'file' access to be
either LOCAL file accesses or FTP file access, if the URL specifies a name
space that cannot be accessed through the local (wide-area) file system.
In fact, part of the software distribution is a simplified x-file protocol
that removes the fallback to FTP.
The second issue, that of defining an AFS URL, is not unrelated to
the first issue. The paper you reference proposes a scheme for
resolving 'file' URLs---for AFS files---that takes advantage of
the ambiguity in the 'file' implementation in most WWW browsers.
We spent several days working on a proposed design for AFS URLs. Earlier
versions of the URL draft proposed something like afs://cell/path. You
mention an afs URL with a proxy/gateway for those without AFS. I agree
with you. However, consider the representation for the AFS url. If
we use the form proposed in the earlier document, the AFS url is really
nothing more than a file path name for AFS users. Non-AFS users need
to know the location of a proxy/gateway or need access to AFS client
software. Transarc briefly looked into a AFS-lite client that could
be included in Web browsers. This is certainly the preferred solution.
The plan was rejected primarily because it would be a significant amount
of work for developers who have other, more pressing concerns (like DFS :-).
I think that Transarc would help any effort to do this.
An alternative is to use the existing proxy facilities provided by
many WWW clients. Again, it is necessary to identify one or more
AFS proxies. The location of gateways is a little hard to distribute
to non-AFS clients. It is even harder to locate "good" gateways
since they should be close to the file server. Joe Average user
cannot just fire up an AFS client and put a proxy server on it.
Also, a single proxy/gateway would be unable to handle
even a small portion of the load necessary to access AFS files (the
public AFS space has 4-5TB of data at 130 sites including CMU, MIT,
NCSA, and CERN, the corporate space is much bigger).
An alternative that we discussed is to register all gateways with a
single name (eg afs.org). The effort to coordinate this seemed
unreasonable. Besides, there is no way to indicate that a particular
gateway is preferred---e.g. the grand.central.org gateway/proxy is
very close to the transarc.com cell, so transfers are more efficient.
An orthogonal issue is that getting AFS: support into browsers will
not happen quickly. We (and other AFS users) would like to use this
today.
So we are left with a dillema... AFS access is faster (most of the
time), has better support for caching and replication, and is more
robust. Obviously, we prefer to get any document we can through
AFS. However, the only way to access AFS documents is to use file:
URLs that use the local file system which cannot be used by non-AFS
clients.
Furthermore, the existing implementation of the 'file' protocol is
precisely what I would propose for an AFS url. I want an AFS path,
and an alternative gateway host and protocol. So here's my proposal
(actually I have some extensions to this for authentication):
afs://{gateway}/afs/{cell}/path
Where the implementation is:
if this is an AFS client then open the file locally
otherwise try to FTP the file from the gateway.
This solves most of the problems. It prefers local file access, but
allows those without access to the local file system to retrieve the file.
The gateway is known to be "good". It is easy to administer and
maintain (we need to make two directories and an AFS mount point
in our FTP server, about 3 minutes work). As an aside, the gateway
must ensuresthat the name space of URLs is identical to the local file
system subject to security requirements. This was one of your complaints.
The proposal is basically the same as the existing 'file' scheme. So,
why not just use 'file'? By the way, there is very little reason to
think just of AFS in these terms. Any file system, assuming it has
an external gateway that exports the name space, fits the model.
--Mic Bowman
> Subject: Re: ANNOUNCEMENT: Free AFS software licenses
> From: Larry Masinter <masinter@parc.xerox.com>
> Date: Tue, 15 Nov 1994 20:21:18 PST
>
> ...
> While the announcement was made on www-announce, I thought it was
> more appropriate to reply more locally, since this is primarily a
> "url" issue. These comments are in response to:
>
> ftp://grand.central.org/afs/tr/public/www/Department/ARPA/Mosaic94/paper.html
>
> The use of the "file:" mechanism to mean *either* local file access
> *or* anonymous FTP access has been deprecated; it was an interesting
> 'pun' that caused serious problems, primarily because the exported FTP
> file space for anonymous FTP access rarely resembled the local file
> space for local file system.
>
> Your proposal for using afs for resolution of afs URLs continue to
> overload those methods in ways that are probably incompatible with
> other existing uses.
>
> It would make more sense, I think, for afs access to be promoted
> through a separate URL scheme, afs, rather than trying to continue to
> overload 'file:' and 'ftp:'. Those browsers/sites that didn't support
> direct afs access could use a proxy gateway for afs translation.
>
> The "afs:" URL scheme got dropped from the (soon to be) draft standard
> for URLs, not for any principled technical reason, but rather that we
> lacked a specification for the interpretation of the scheme.
>
> I am enthusiastic about the intent of your proposal, in that AFS does
> indeed provide a mechanism for replication and caching that will be of
> great use on the Internet. I hope you will consider modifying it, and
> your sample source code release, however, to be more compatible with
> current directions in URL standardization.