On 3/4/07, Edi Weitz edi@agharta.de wrote:
On Fri, 2 Mar 2007 22:44:42 +0100, "Erik Huelsmann" ehuels@gmail.com wrote:
This means I have 3 choices:
- return both the stream and the socket object in the return values
- 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?
I'd prefer (3) because it means we don't have to change Drakma and I won't have to do any work (for which I don't have time right now).
I figured so much, so I've been working to make the API support (3). It looks like I'll be able to make it so.
But I can live with (1), if you provide a clean patch for that - including all the necessary updates to docstrings and the HTML documentation...
I'll regard (3) as a minimal version. I can submit a patch for (1) which will ofcourse change the docs and docstrings. For now, I'll focus on (3) though.
What is the additional usocket functionality we'd lose if we opt for (3)?
It won't be possible to support any other function than reading/writing content on the socket. Other functionality includes retrieving the local or remote socket 'names' (ip+port). I hope to support read/write timeout settings in the future too. That functionality won't be available (outside of http-request; internally, it could bind the usocket, ofcourse).
I hope that answers your question.
bye,
Erik.