[drakma-devel] Re: Portability of Drakma

[Erik Huelsmann]

On 2/25/07, Edi Weitz <edi at agharta.de> wrote:
> On Sun, 25 Feb 2007 14:38:02 +0100, "Erik Huelsmann" <ehuels at gmail.com> wrote:
>
> >>   - The code should have been tested successfully on at least the
> >>     Lisp/OS combinations that are currently supported by Drakma.
> >
> > Is there a list somewhere as a reference to what I'm getting into?
>
> No, unfortunately not.  I myself use mostly LispWorks (Windows and
> Linux/x86) and SBCL (Linux/x86).  (LispWorks shouldn't be a problem
> anyway as it's not affected by the switch.)
>
> I think that at least LispWorks, SBCL, AllegroCL, CMUCL, CLISP, and
> OpenMCL should be supported, everything else being a bonus.  Operating
> systems: Windows (where applicable), Linux, OS X.
>
> If you don't want to test all of this for yourself, how about offering
> a tarball of Drakma which uses usocket for download?  Send an
> announcement to this mailing list including an overview of what you've
> tested and what not.  We can ask "interested parties" to try it out
> and we'll switch to the new version in four weeks, say, unless someone
> objects.  Does that sound OK?

Sounds great. I did an initial port which works, but I then realised
it doesn't exactly conform to the current usocket API :-(

What I did was bind the socket-stream associated with the usocket
object instead of the open-stream return value by trivial-sockets.
That will work on all (current) implementations, but doesn't really
conform with the API. The only benefit will be that Drakma runs on
more platforms, but none of the additional usocket functionality can
be used (as the usocket object itself can't be retrieved from the
stream).

This means I have 3 choices:

1) return both the stream and the socket object in the return values
2) use trivial-usocket: the trivial-sockets portability library which
associates a usocket with a gray stream. Closing the stream will close
the socket. But it adds another (rather useless IMO) call for every
socket stream operation. Also, trivial-usocket has a smaller supported
set of implementations than usocket does.
3) slightly violate/change the usocket API to require changing the
stream to be a valid action for closing the socket.

So, my initial reaction would be to change the http-request interface:
still returning the http-stream return value, but return also a
seventh value: the socket. On input we'd require the stream and the
socket when the :stream key is supplied.

But I could live with (3) as well.

Do you have any preferences?

bye,

Erik.