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.
[1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathname...
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 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.