| Date: Sun, 02 Jan 2005 14:31:43 -0800
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | It seems rather behind-the-times to talk about "a place
 | in the file system."   In 2005 we should be using the
 | language of URIs to talk about "places".

Any application program which is composed of more than one file, has
libraries, uses ancillary data, is customizable by the user, or
maintains project state must deal with places in the local file
system.  Even a program which must go to network to retrieve resources
must store those files locally.

 | I suggest re-working this SRFI to talk about URIs rather
 | than vicinities.  Specifically, replace "base vicinity"
 | by "absolute URI".
 |
 | The in-vicinity function should be replaced by a
 | "resolve-uri" function which "resolves" a URI (possibly
 | relative) against a "base" (usually absolute) URI.

How does the program write files to a URI which is not a file://?
Some of the vicinity uses mentioned above write files.

 | The user-vicinity function could be replaced by a "base-uri"
 | function, which default to the "current directory".

The specific vicinities provided by SRFI-59 default to different
places in the filesystem.  The abstraction of those defaults is the
main content of SRFI-59.

 | Note that in practice one can view a filename/-path as a
 | URI relative to the current directory without ambguity except
 | for some rare pathological cases.  (Among the latter are
 | filenames containing '%'.)  So one appealing option is to
 | generalize load, open-input-filename etc to take a URI *or*
 | filename:
 |    (load "http://foo.com/bar.scm")
 | If the string is a relative URI, it is resolved relative to the
 | value of base-uri, which defauls to the current directory.
 | I've been toying iwth implementing this for Kawa, but haven't
 | gotten around to it.

SLIB/uri.scm implements RFC2396.  It is a general system, perhaps the
modern analogue of the Common-Lisp pathname facility mentioned in
Rationale.  I am aware of the use of URIs.

But the point of the Rationale was that a general pathname facility
requires a great deal of system-specific knowledge to portably resolve
the handful of specific vicinities which will be of interest to an
application.

Vicinities get the job done with much less hassle.

 | The Java API for the URI class provides a useful summary
 | from an API focus:
 | http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html
 | RFC 2396 is the actual standard: http://www.ietf.org/rfc/rfc2396.txt