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

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.

The user-vicinity function could be replaced by a "base-uri"
function, which default to the "current directory".

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.

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