This page is part of the web mail archives of SRFI 59 from before July 7th, 2015. The new archives for SRFI 59 contain all messages, not just those from before July 7th, 2015.
| Date: Sun, 09 Jan 2005 23:30:03 -0800 | From: Per Bothner <per@xxxxxxxxxxx> | | 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.