[armedbear-devel] URL pathname code in trunk

Mark Evenson evenson at panix.com
Thu Apr 15 15:10:37 UTC 2010

I've pushed the code for handling URLs in pathnames to the trunk in 
commits r12605-r12616.

The [design documents what I was aiming for][1], namely allowing 
resources addressed by URL (i.e. a URI with a network authority) to be 
used as Lisp pathnames.  I expect that this will work for anything that 
'java.net.URL' works with, although I have yet to "shake down" the OSGi 
code using the "bundle:" scheme.  After I push ASDF2 to the trunk, this 
will be the goal my next effort.


Incomplete at this point:

1.  The implementation is lacking proper URI/URL escaping.  I intend to 
not have anything automagically happen, but rather provide functions for 
the user to encode/decode pathnames to string forms.  It is a matter of 
writing (stealing?) decent URI escaping code at this point.

Noteworthy changes:

1.  JAR-PATHNAME and URL-PATHNAME are now subtypes of PATHNAME.

2.  Both JAR-PATHNME and URL-PATHNAME are now valid arguments to OPEN 

3.  QUERY and FRAGMENTS are stored in the HOST plist.  Not my favorite 
part of the design, but better than any other choice I could come up 
with.  Users are expected to use the DEFSETF PATHNAME-URL-QUERY and 
PATHNAME-URL-FRAGEMENT functions to manipulate these quantities.

4.  Fixed some fugliness with *LOAD-TRUENAME* and *LOAD-PATHNAME* with 
jar pathnames returning more of the expected values.

5.  Jar pathnames use of a String to denote URLs has been replaced by 
the use of proper URL pathnames.  If someone has code that I have 
brooken because it depended on the internal structure of jar pathnames 
from 0.19, shout out, and we'll figure out something.  Hopefully, 
everyone was using namestrings anwyays, so everything should "just work".

Feedback, bug reports, success stories welcome.

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

More information about the armedbear-devel mailing list