[armedbear-devel] Proposal for URL to be used as Pathnames
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] 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.
> 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
>> 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.
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