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

[Mark Evenson]

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 
URL-PATHNAME-AUTHORITY, URL-PATHNAME-HOST to allow the user to 
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 
well.

>> 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."