[Openmcl-devel] Lisp for the 21 century: how to deal with URLs

[Dan Weinreb]

Alex,

The main question is: are there things that are important to do
with URL's that can't be provided with a library?

Do we really want functions that take pathnames to also
take URL's?  Even if we do, is that particularly important
to have?

Suppose we had a library called "URL", in package "url",
implementing an abstract class called "url".  We define
generic functions such as:

(defgeneric load-program (url)
  "The argument is an object of type url:url.
   Get all the characters from the resource identified by URL,
   and read and evaluate each one.  If such-and-such happens,
   signal condition such-and-such; if such-and-such... etc etc
   Otherwise it has succeed, and returns whatever.")

Then anyone can make an url:url, and call url:load-program.
(I'm not sure that's the very best possible name but it'll do
for purposes of this email.)

If you want to load a program that's stored in a file, you can
use the "file" scheme [Note: "scheme" means the thing at
the beginning of the URL, before the colon].

We would either define the "file" scheme to be interpreted
the same way that Lisp pathname functions interpret strings,
or else we might have to make up a new scheme for that,
depending on the exact specs of the "file" scheme in the
URL RFC (I'm too lazy to check right now).  Then you
could use load-program with logical pathnames or any
other kind of Lisp pathname.

As Rainer said, logical pathnames are solving a different
problem, so we would not want to get rid of them.

At the implementation level, there would be a subclass
of url:url for each scheme, and a defined way for an
application/library to add support for a new scheme, e.g.

(url:add-scheme "svn" 'svn:svn-url)

where "svn"" is a Lisp package that knows about Subversion,
and "svn-url" is a subclass of url:url defined in the svn package.
The svn package then does

(defmethod url:load-program (u (svn:svn-url))
   ...)

which knows how to access an svn repository, for example.

>
> At an implementation level, in CCL, one could start by hacking load.  
> If the pathname is a string starting with "http://" then the chance is  
> pretty good 
I'm not a big fan of this kind of heuristic, that depends on chances
being pretty good.  I prefer nice, clean, deterministic, simple
contracts.
> The file could be downloaded via HTTP, perhaps as temp file, and then  
> loaded the "old" way. 
Yes, you could either stream it or buffer it; that's entirely an
implementation question, having nothing to do with the
"in the language" vs. "in a library" question.

 From a practical point of view, doing it as a library
would let it be portable, so that we would not have
to get all eleven CL implementations to (a) agree on
the spec and (b) release new versions.  Roger
Corman, for example, doesn't have anybody to help
him, and he doesn't have a lot of time to work on
his implementation.  I suspect some of them others
are in similar positions.

(Note that in real life, you'd probably want to talk
about "uri"'s rather than "url"'s, and you'd probably
want to use the existing "puri" library by Kevin Rosenberg,
and so on.  The above is just conceptual.)

-- Dan
>
>
> Prof. Alexander Repenning
>
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>