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, 02 Jan 2005 14:31:43 -0800 | From: Per Bothner <per@xxxxxxxxxxx> | | 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