URN/URL file links

Kevin Altis (kevin@scic.intel.com)
Tue, 14 Sep 1993 08:47:17 -0800

One idea I've batted around for a while is putting a single URL or URN
(when available) in a file (so it would be a one line text file) and then
name the file with the link name that would normally appear in the body of
a HTML document or on an anon-ftp site. Then a small application (or maybe
the various WWW clients) could be used that would be able to "launch" the
file and invoke an appropriate viewer for .au, .mpeg, .ps, etc. then the
application would quit; sort of drag and drop on Macs, hopefully a quick
perl script in Unix. If possible, a user should be able to launch multiple
copies of the application to get multiple files simultaneously. The
extension in DOS, Unix, etc. would obviously be .urn or .url depending on
the file content.

The application ideally would be small, no viewing or editing, only
settings for which viewers to invoke after the application had retrieved
the document. This would be a simple way of extending any OS file system
with URLs and URNs. The penalty would be the minimum file size of the disk
the file is stored on. This has implications for Hotlists in Mosaic and
other WWW clients, because a given OS hierarchical file system would
provide the organizational control for the files containing the URLs and
URNs. Normal soft and hard links, aliases, etc. to the file could still be
used to put the references into multiple folder/directory categories. This
would also work for providing indirect links via FTP or the local file
system. For example, a single file at CERN might contain the URL pointing
to the latest PostScript version of the draft URL spec. (url5.ps, url6.ps,
etc.). HTML and HTML+ documents would point to the "url.url" file at CERN,
which when retrieved would get you the latest version of the draft.

Finally, the Web doesn't support two way links such Object Oriented Database. The double indirection approach will hopefully
take care of part of the problem with references to specific versions of
files which leave lots of invalid links around the Web; the HTML and HTML+
specs. don't specify a way of dealing with two way links at this point. I
suspect that this kind of approach may also take away a lot of need for
specific gopher clients, since you won't need a gopher client to present a
directory to you to retrieve a lot of common net objects, the directory
will already be provided by the OS.

Kevin Altis
Intel Corporation
Supercomputer Systems Division
Internet: kevin@scic.intel.com