[armedbear-devel] Proposal for URL to be used as Pathnames

Mark Evenson evenson at panix.com
Fri Apr 2 08:59:49 UTC 2010

On 4/1/10 5:08 AM, Alan Ruttenberg wrote:
> On Mon, Mar 29, 2010 at 5:07 AM, Mark Evenson<evenson at panix.com>  wrote:
>>  At the moment I'm favoring just implementing such
>> a specializer for "http" and "bundle", creating a protocol for a user to
>> add a specializer, and calling it a day.
> + ftp, https, urn, info would all be common in my world.

I currently intend to only implement URIs that can be dereferenced with 
respect to the network authority, which is why I call these things "URL 
pathnames".  Something like "urn" or "info" that needs a resolution 
mechanism are not such good fits for CL Pathnames as far as I can tell, 
as the primary motivation here is to get LOAD and OPEN working for 
objects that java.net.URL (and its extensions via 
java.net.URLStreamHandler) can construct.  I think if we want real URIs, 
I think we should look at using [PURI][1] as I don't think that 
java.net.URI has a schema specific escaping mechanism.  If I implemented 
a method to convert from PURI <--> ABCL Pathname where possible, what 
that be suitable for your needs.

[1]: http://puri.b9.com/

> btw, I'm not sure mixing the authority and port is the best choice -
> they tend to be separate items.

As I understand it "authority" is "host" plus (optional or implied) 
"port".  I intend to implement SETFable functions like URL-PATHNAME-PORT 
manipulate this value.

> Also, how to do fragments ("#anchor") and queries (?q=blah)  for http URIs?

A good question for which I'm not entirely happy with my current answer: 
  just incorporate them in NAME, while providing functions like 
URL-PATHNAME-QUERY and URL-PATHNAME-FRAGMENT to allow manipulation.  The 
other possibility I considered was somehow overloading the information 
in TYPE (make TYPE a LIST?) but that seems to have ambiguity problems as 

>> Do we want the namestring to always be the encoded form?  I was planning
>> to have the namestring be what the user used to create the URL-PATHNAME,
>> but always encode before going to the network.  I need to think about
>> this more.
> It's a good question. The thing is that with an http URI you want to
> be able to format it for inclusion in a web page, or to execute an
> http get on it. So you need to access the encoded form in an easy way.
> I'm leaning to namestring as the way of retrieving that, but I suppose
> it doesn't matter as long as their's some function.

We'll make functions then.  I suppose we need four:  two variants to 
handle the inputs of string or pathname crossed with decoding or encoding.


> I hadn't thought about wild cards at all. Maybe the use of logical
> pathnames for this is overambitious and I should think of this
> facility for URLs and retain my current system for dealing with URIs.
> http://mumble.net:8080/svn/lsw/trunk/util/namespace.lisp
> http://mumble.net:8080/svn/lsw/trunk/util/uri.lisp

My preference would be to get de-referencable URIs (aka URLs) working 
first, and then look at implementing further stuff on top of that.  I 
believe that sorting out how to handle such things probably be handled 
in libraries external to ABCL.  I think that as long as we can get 
'http', 'https', 'ftp', and 'bundle' URLs working with LOAD and OPEN 
(and MERGE-PATHNAME, PROBE-FILE, MATCH-PATHAME-P, etc.), we're going to 
cover most of the usage out there.

"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