client local file system access issues
altis@ibeam.jf.intel.com (Kevin Altis)
Errors-To: postmaster@www0.cern.ch
Date: Tue, 15 Feb 1994 13:08:36 --100
Message-id: <m0pWCpu-00042YC@ibeam.intel.com>
Errors-To: postmaster@www0.cern.ch
Reply-To: altis@ibeam.jf.intel.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: altis@ibeam.jf.intel.com (Kevin Altis)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: client local file system access issues
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2823
Getting all clients to do file://localhost
file://localhost/path
First of all, is this standardized or not? We have people all over the net,
using file:// instead of ftp:// for ftp accesses, which is a pain. 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.
---
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