> So, what is a way that, give only the knowledge of the first URL, you
> can find the second URL?
It looks like this "mapping" to AFS would have to occur at the http
server level since it is the only one that knows the relation of the
relative URL (path starting at the server's root directory) to the real
AFS path. But then, the client program has to tell the server that it
can handle the remapping (can see /afs).
Speaking as one of the people who maintains the server Derek's talking
about..
a) it could use an afs: URL similar to the wais: URL (if you can do
(AFS,WAIS) you do, and if you can't, you use a gateway. This was
proposed and tentatively added and then removed from the developing
spec, unless I missed something.
b) the server could tell you to just use AFS. This functionality
exists already in many server and client implementations (URL
forwarding). This is a win in that you don't have to trounce the
server's AFS cache, but it still involves http server overhead, and
so isn't nearly as nice a win as you'd like.
c) you could solve the problem by avoiding it. Specifically, you
could keep a translation table that would map
`http://www.mit.edu:8001/afs' to `file://localhost/afs'
(incidentally, you can of course use this kind of URL for
/etc/named.boot as well; I'm not sure what Peter Lister is talking
about wrt this). This is the method that Ted Ts'o implemented (as
Bill Sommerfeld mentioned). This is being used by a few people
both ways (to go through AFS for speed and to go through the http
AFS gateway for machines without AFS) here now, and it seems like a
good idea; I'll probably be applying the changes here to our
clients and forwarding them off to the world (with Ted's
permission, of course, which I believe I have).
d) you could use a really smart client. Don't hold your breath. :-)
Personally, I remain unconvinced that a) isn't the way to go, but I've
been too busy to seriously pursue it with the relevant people - if it
happened, we'd need some volunteers to be AFS gateways. I envision
this as something that allows unauthed access, just becuase that's the
way it is now. With a good auth method, this could one day be beaten
into an alternative AFS transport layer to client machines without AFS
(MIT just wired it's undergrad living groups, and AFS access to
non-workstations is a hot issue).
That aside, c) is a useful, useable solution for the near future, and
I expect to use it here sometime soon. (thanks, Ted!)
chad
<a href="http://www.mit.edu:8001/people/yandros/home_page.html">chad</a>
