On Fri, Mar 26, 2010 at 12:29 PM, Mark Evenson evenson@panix.com wrote:
On Mar 26, 2010, at 10:16 AM, Ville Voutilainen wrote:
On 26 March 2010 10:44, Alessio Stalla alessiostalla@gmail.com wrote:
FWIW, CLForJava also represents URLs as pathnames: http://clforjava.org/Documents/ELS%202008%20-%20Abstraction%20of%20Pathnames...
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:
- 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).
- 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.
- 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.
- I don't see any real use of mapping URIs like
"mailto:username@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.
- 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:
- It validates my abstraction that the a URL can
be meaningfully decomposed into three parts, namely the scheme, the authority, and the path.
- 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.
- 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