[drakma-devel] Re: Portability of Drakma

[Erik Huelsmann]

On 3/4/07, Edi Weitz <edi at agharta.de> wrote:
> On Fri, 2 Mar 2007 22:44:42 +0100, "Erik Huelsmann" <ehuels at gmail.com> wrote:
>
> > 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?
>
> 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.