[armedbear-devel] URL pathname code in trunk
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
The [design documents what I was aiming for], 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.
1. JAR-PATHNAME and URL-PATHNAME are now subtypes of PATHNAME.
2. Both JAR-PATHNME and URL-PATHNAME are now valid arguments to OPEN
with :DIRECTION :INPUT.
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