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.
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 per@xxxxxxxxxxx http://per.bothner.com/