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?  And if on a
network filesystem, why not the web, which is just a large
distributed network file system?

> Even a program which must go to network to retrieve resources
> must store those files locally.

Er, no.  I can open a socket and read/write from/to it, just as I can
read/write a local file.

>  | 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://?

You can write to an ftp: URI.  You can write to an http: URI using
a POST command.  WebDAV is "a set of extensions to the HTTP protocol
which allows users to collaboratively edit and manage files on remote
web servers" (webdav.org).

> 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.

I don't understand what "system-specific knowledge" you're concerned
about.  Standard URI resolution basically handles Unix (and hence
Mac OSX) pathnames as is.  Windows are more-or-less the same, except
for allowing '\' or '/' as directory separators, and having drive
letters.  If anybody is using more arcane systems, they presumably
can handle file: URIs, and in any case pathname resolution would be
hidden inside a library.

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

Of course I'm suggesting we require support for any specific protocol.
Only that we use the standard way of naming facilities.

> Vicinities get the job done with much less hassle.

Vicinities that aren't general enough to handle URIs don't get the job
done.  There's no point bothering to define an API for them.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/