| Date: Sun, 09 Jan 2005 23:30:03 -0800
 | From: Per Bothner <xxxxxx@bothner.com>
 |
 | Aubrey Jaffer wrote:
 | > 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.
 |
 | Why?  Why can't these be on a network file system?

I shouldn't have used the word LOCAL, which does not appear in the
text of SRFI-59.  Of course networked file systems are
indistinguishable from local.

 | And if on a network filesystem, why not the web, which is just a
 | large distributed network file system?

I will rewrite it to permit 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.
 |
 | The Common Lisp pathname facility is overkill because there is
 | little reason to use anything other than strings for pathnames.

Yes, we agree.

 | Once you do that, there is little reason not to generalize to URIs
 | - A pathname that starts with a URI scheme (i.e. an initial name
 | followed by a colon, where the name must be more than one character
 | to avoid confusion with DOS-style drive letters) is an absolute
 | URI.  Any other pathname is either a local filename (if it is
 | resolved to a "base" file: URI or a local directory), or a relative
 | URI (otherwise).

This would seem to assume there is a base-URI to be relative to.

All the vicinities except USER-VICINITY should be absolute.
Only USER-VICINITY is relative to the current directory, and that may
not be a well-defined concept on some platforms.

About this RFC 2396 says:

 5.1.4. Default Base URI

   If none of the conditions described in Sections 5.1.1--5.1.3 apply,
   then the base URI is defined by the context of the application.
   Since this definition is necessarily application-dependent, failing
   to define the base URI using one of the other methods may result in
   the same content being interpreted differently by different types
   of application.

   It is the responsibility of the distributor(s) of a document
   containing relative URI to ensure that the base URI for that
   document can be established.  It must be emphasized that relative
   URI cannot be used reliably in situations where the document's base
   URI is not well-defined.

Are you assuming that absolute pathnames are generally allowed as
filename arguments?  That is not my intent:

   `in-vicinity' should allow FILENAME to override VICINITY when
   FILENAME is an absolute pathname and VICINITY is equal to the value
   of `(user-vicinity)'.  The behavior of `in-vicinity' when FILENAME
   is absolute and VICINITY is not equal to the value of
   `(user-vicinity)' is unspecified.

Vicinities are about capturing and abstracting the base URIs programs
need to run.  Vicinities are not about general URI resolution.