My initial code to get LOAD to use "jar:file:" was rather hackish in that it didn't consider enough scope of the impact so I've been looking hard at implementing TRUENAME, PROBE-FILE, MERGE-PATHNAMES (and eventually PROBE-DIRECTORY and DIRECTORY) for "jar:file" entries. I'd like to propose we change the use of the "jar:file:" string to only occur in the namestring representation of a jar file entry, i.e. the device entry would always be a "real" pathname.
So what would currently be
CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "jar:file:abcl"
which would become
CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "abcl"
under my proposal.
This would simplify the needed code quite a bit as one just has to detect we are dealing with a jar entry reference, pull the pathname out of device, and pass it to a sub-routine.
And according to the unofficial specification of the "jar:file" URI schema, it is invalid not to have a reference to the entry by the path following the "!/" (i.e. "jar:file:abcl.jar" has no meaning, just "jar:file:abcl.jar!/foo").
I've started to implement this, but would like to float this idea across the list to see if there are objections and/or problems I've not foreseen.
I've managed to go pretty far down the road to implementing "jar:" references "correctly" into ABCL so some closing notes for the night:
Alan Ruttenberg noted in private communication that [the javadoc for java.net.URLConnection][1] has a pretty decent "specification" of what I am trying to do, with the caveat that I am only implementing the "jar:" for URIs in the "file:" schema. This suggests that we should look to making PATHNAME more generic in supporting schemas like "http:". This would all presumably thunk down to the support in java.net.URL, and only be practically used for the "file" and "http" schemas. We might have a problem with pathnames in that their namestrings could never start with "file:" or "http:", but maybe we would be willing to sacrifice strict CL compatibility here for a more natural fit. After all, we currently have that for files that are called "jar:file:baz.jar!/foo". My hunch is that there will be always be corner-cases in the pathname back and forth to namestring interface that will always exist which is inherent in the ANSI CL specification in that in leaves the actual semantics of DEVICE, HOST, etc. up to implementations.
[1]: http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html
The documentation for JarURLConnection indicates that a URI that references the JAR itself must always end in "!/" like
jar:file:baz.jar!/
This makes my previous insistence that (pathname-device #p"jar:file:baz.jar!/foo") return "baz" instead of "jar:file:baz.jar" a little less necessary, so I will revisit this decision, especially in light of the need for recursive jar file references.
The recursive entries arrise if I am going to implement the TRUENAME stuff correctly (which will make the current LOAD code a lot less hairy). Consider a JAR archive called "baz.jar". It contains an ABCL packed FASL known as "bar.abcl" (i.e. "bar.abcl" is itself a JAR containing "bar._", "bar-1.cls", "bar-2.cls", etc.). To reference the first FASL stored in "jar:file:bar.abcl!/bar-1.cls", I propose use the seeming monstrosity:
jar:jar:file:baz.jar!/bar.abcl!/bar-1.cls
Seems to logically check out in my head, but if others spot an error please chime in.
And the current implementation fails with
load("jar:file:baz.jar!/bar")
anyways as this is the part that started failing with the recent AutoloadedFunctionProxy implementation.
armedbear-devel@common-lisp.net
-
Mark Evenson