>Getting all clients to do file://localhost
I was noticing that XMosaic did this. My understanding of the 'file'
protocol specifier was:
1. try to get it via ftp
2. if that fails and no host name was specified, try to treat it
as a local file
I don't know if maybe 2. comes before 1. This would be pretty important
in the following case-
Suppose there is a /tuna file on my machine AND a file called
tuna in the root directory of the anonymous ftp server on this
same machine?
If I were writing a WWW client (which, in fact, I am) I'd be inclined
to say that if a host is specified (even localhost) then 'file'
_really_ means 'ftp'; otherwise it means 'file'.
As an aside, the URL spec <file://info.cern.ch/pub/www/doc/url-spec.txt>
makes no mention of the 'file' protocol type.
>file://localhost/path
>Local
>file access doesn't really seem to be standardized. Here are some examples:
>
>Lynx and X Mosaic both do file://localhost/path
>path is the full path from the root (/) of the local filesystem.
>Cello does file://localhost/c:/path
>c could be any drive letter.
>
>Mac Mosaic does file:///drive name/path Spaces are okay at least in the
>drive name.
>
>Win Mosaic does file:///c|/path
>c could be any drive letter.
>
>
>I think that clients could probably treat the drive letter (DOS/WINDOWS) or
>drive name (Mac), etc. as just the first path element, so that the path
>wouldn't look any different than their Unix cousins:
>file://localhost/c/path or file://localhost/drive name/path
>The key is that all clients have to conform to using file://localhost/ to
>mean part of the local file system.
What's so great about /'s?
I don't know too much about DOS and Mac's but isn't it possible
to construct a single absolute (path/string) that points to a file
including drive? If that's true, what's the need to litter it with /'s?
I'm nearly certain that's the case w/DOS.
This causes a problem if you still want to use partial URLs.
I think there's a lot of confusion regarding the semantics of the /
in urls (especially for nonUnix-style systems). I know I'm confused.
>---
>Local aliases
[ stuff deleted ]
>(especially my portable where I don't always have a net connection). Of
>course, I would want to reference those local files and not have the URLs
>break at a later date.
>
>What's needed of course is the ability to do client side aliasing, just
>like HTTP servers allow today. The client would support a setup such as:
>
>Alias file://localhost/c/somedir/anotherdir file://localhost/i/anotherdir
>
>All the URLs referencing those local documents would still work, even
>though the actual file system location on the local machine has changed.
Don't partial URLs fix this problem already? Or at least part of it.
>---
>The last issue is when dealing with local files, there is no particular
>reason that clients should bring a document from part of the local
>filesystem to another part of the local filesystem before displaying the
>file or handing it off to an external browser. So, the case of
>file://localhost should be treated special be the client so that it just
>goes and used the local file. You won't have to wait for a 14MB audio/video
>file to get copied to a different directory before the external mpeg player
>launches to play the file.
>
>Comments?
This is strictly a client design decision. If you're looking at a local
file then, naturally, you shouldn't copy it around. If 'localhost' has
magical meaning--the thought of which makes my skin crawl, then that's
another matter.
>
>ka
>
>
-reed
-- wade@cs.utk.edu -- http://netlib2.cs.utk.edu/people/ReedWade.html