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

[Alessio Stalla]

On Fri, Mar 26, 2010 at 12:29 PM, Mark Evenson <evenson at panix.com> wrote:
>
> 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.

I completely agree. I actually just skimmed the CLforJava paper; I'm
glad you found it useful. The broken fragment handling stroke me too,
but I didn't go much deeper than that.

Incidentally, I learned that the maintainer/main developer of
CLforJava will give a talk at the ELS. I will probably be there; I
hope to learn something useful for ABCL, too.

Bye,
Alessio