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.
--- Local aliases Given that all clients will then reference local files in a standard way, it becomes possible to imagine distributing a set of files across systems and building hyperlinks to reference local files seamlessly with other Web documents. An obvious reason to do this would be for inlined gif images, help files, or large static files that you don't want clients pulling across the net every time they access an HTML page (like Tim's Internet Talk Radio interview). You could even use least common denominator file and directory names (DOS style filename.ext) so that the same group of files would work across Unix, Mac, and DOS/Windows. I can think of lots of static pages on the net that I wouldn't mind keeping on my local filesystem (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.
--- 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?
ka