Re: [armedbear-devel] Proposal for URL to be used as Pathnames
Mark Evenson <evenson <at> panix.com>
2010-04-02 08:59:49 GMT
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."
RSS Feed