[armedbear-devel] More on proposed change to jar:file semantics

[Mark Evenson]

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.

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