[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comment on vicinties vs URIs

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.

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*
  (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:
RFC 2396 is the actual standard: http://www.ietf.org/rfc/rfc2396.txt
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/