On 4/1/10 5:08 AM, Alan Ruttenberg wrote:
On Mon, Mar 29, 2010 at 5:07 AM, Mark Evensonevenson@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.