[armedbear-devel] Proposal for URL to be used as Pathnames

[Mark Evenson]

On Mar 26, 2010, at 10:16 AM, Ville Voutilainen wrote:

> On 26 March 2010 10:44, Alessio Stalla <alessiostalla at gmail.com> wrote:
>> FWIW, CLForJava also represents URLs as pathnames:
>> http://clforjava.org/Documents/ELS%202008%20-%20Abstraction%20of%20Pathnames%20and%20Streams.pdf
> 
> In that case it would be good to be compatible with their scheme<sic>.
> Unless there's some problem with
> that.

From what I can understand from the paper Alessio referenced
(thanks!), I don't think we want to use their abstraction
in terms of Pathname components for the following reasons:

1. ClForJava *always* fills in the DEVICE component to contain the
URI scheme, meaning that even ordinary files get a DEVICE containing
a :FILE symbol.  We would have to retrofit all the existing code
for ordinary pathnames for no apparent gain which already works
just fine.  This use of a symbol in DEVICE is also incompatible
with ABCL's use of DEVICE under windows to contain the drive letter.
And it is incompatible with jar pathnames' use of DEVICE to contain
the Pathname(s) of the jar(s).

2. I don't see an easy way to represent a jar pathname which needs
to both contain one or two Pathnnames for the enclosing jars in
addition to the reference to the entry in the jar.  Part of the
reason for this is that "jar URLs" are actually not URLs but a
larger protocol that uses URLs to specify the location of the jar.
Since as I understand the CLForJava design, which dictates that all
Pathnames have a DEVICE which is a symbol, and a HOST which is a
string, we don't have much room left to implement jar pathnames.
We *could* wedge the jar URL in the DIRECTORY along with the entry
path, but it wouldn't make much sense when someone tries to
MERGE-PATHNAMES such a beast without a lot of special casing.

3. The incorporation of the URL fragment and query in the DIRECTORY
is just wrong.  Logically these elements belong as subordinate to
the NAME i.e. for "http://example.org/command/search?s=demons" and
"http://example.org/command/expel?s=demons" the query "?s=demons"
should be associated with the NAME ("search" or "expel" rather than
pushed to the DIRECTORY as "(:ABSOLUTE "command" "?s=demons").  And
a fragment is even more strongly associated with the semantics of
being a subaddress of the URL.  It would make more sense to wedge
the URL fragment and query components into TYPE if anything.  And
I don't expect MERGE-PATHNAMES to react sensibly to this design
without a lot of special casing.

4.  I don't see any real use of mapping URIs like
"mailto:username at example.org" or "urn:some.really-opaque-234234234-string"
to Pathnames.  If one can't OPEN and LOAD a Pathname, what's the
point?  If you want a generic URI interface use PURI or something.

5.  The use of HOST as a String which contains the URL authority
portion is ambiguous with respect to the use of HOST for logical
hosts.  It is not immediately obvious from the paper how one
distinguishes the two cases. I presume CLforJava does not have an
implementation of logical pathnames to worry about.

What I *like* from the CLforJava paper:

1.  It validates my abstraction that the a URL can
be meaningfully decomposed into three parts, namely the scheme, the
authority, and the path.

2.  The use of additional "PATHNAME-*" functions to extract parts
of the URL (like PATHANME-SCHEME to extract the scheme).  The paper
doesn't indicate whether these are SETF-able places, but that would
be an obvious implmentation choice.

3.  It validates the choice of :ABSOLUTE in DIRECTORY URL components.

Since the namestrings from the two implementations will be compatible,
which is mostly how I can imagine them sharing code in ASDF, I would
propose that we do not adopt the CLforJava Pathname component scheme.
Adopting it would require a) refitting "ordinary" Pathnames, b)
figuring out some method of expressing jar pathnames, and c) just
using a broken idea of fragments and queries at the DIRECTORY.  What
I would propose to do is make a series of SETFable PATHNAME-URL-SCHEME,
PATHNAME-URL-PATH, etc. methods to facilitate working on the Pathname
structure.



--

"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."