On 2/25/07, Edi Weitz edi@agharta.de wrote:
On Sun, 25 Feb 2007 14:38:02 +0100, "Erik Huelsmann" ehuels@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.