First of all, my apologies to info-afs. I could have sworn that this thread
started on www-talk. This is my last word on the matter on info-afs; I shall
send any further thoughts to www-talk.
Bill Sommerfeld notes several good reasons why AFS is a nice file system and
provides information more reliably than HTTP. Yes, OK, I love AFS dearly as
well. My point - which I didn't put very well, like I usually don't - is that
I would far prefer that effort be put in to HTTP browsers and servers to make
authentication and failover happen to the benefit of all WWW folk, rather than
making Mosaic fit AFS.
As several people have noted - the mapping of an http: URL to a file: URL is
not trivial. Especially when (like ours) an HTTP server with files in AFS
(therefore apparently visible to AFS) also has different CGI scripts mapped to
http: URLs. How do clients know that one URL maps to a script, and hence must
be pulled via HTTP, but another is a file, and could be pulled via AFS? OK,
you can have a configuration file, as suggested. How do I, a server admin,
then tell AFS aware clients that a new service now exists, mapped on to this
URL, which would previously have been assumed to be a file?
[EMAIL PROTECTED] describes a few options
> a) it could use an afs: URL similar to the wais: URL
Yes, fortunately that was dropped. What does afs: achieve that file: does not?
For none AFS machines, an AFS gateway is just an (http:,ftp:) server which can
see /afs. If an HTTP server at AFS site wishes to serve references to
file://mysite/afs/..., then it's perfectly free to do so. I really don't see
the need for another URL type.
> (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
Yeah, OK, it was late and I forgot that there's no named.boot on this machine.
:-) My abject apologies.
> d) you could use a really smart client. Don't hold your breath. :-)
By which I assume you mean a system which can translate URNs etc. Well, I must
say that with the phenomenal growth of WWW in the last year, I wouldn't
dismiss the idea that something which does this sort of thing may be far off.
My point is that if there's a great deal of effort involved in getting this
kind of thing working (and the effort required for this kind of thing should
never be underestimated), please can we keep as much work as possible AFS
independent.
The idea of HTTP as an alternative AFS transport layer is very attractive, but
it implies that HTTP needs beefing up to do Kerberos authentication and better
caching, neither of which are intrinsically AFS specific!
Peter Lister Email: [EMAIL PROTECTED]
Computer Centre, Cranfield University Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 234 750875
--- Go stick your head in a pig. (R) Sirius Cybernetics Corporation ---
