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
Kevin Altis
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.
Intel Corporation
Supercomputer Systems Division
Internet: kevin@scic.intel.com