Yes, I have been thinking about that a bit. I think the solution to that
(it doesn't expose the raw socket but gives "raw io control") is something
like this:

curl_read(handle, char* buf, len) and curl_write(handle, char* buf, int
len), curl_close(handle), etc.

So that you control driving data into the handle vs. via callbacks.

Reasons for doing this? One issue I looked at was putting a C++ streams
interface around curl for I/O. Callbacks make this a much more complex
task than the a read/write ability.

We have cases where we perform certain filtering on incoming/outgoing data.
Certain things are byte-bondary dependent. There is a little extra buffer
management we must do in our callback classes that we could avoid if we had
the read/write mechanism since you have greater control over the i/o.

The multihandle select is good for knowing when you want to read/write but
it still does not give the app as much control over the actual i/o as it
may desire.

|---------+---------------------------------------->
| | Daniel Stenberg |
| | <daniel_at_haxx.se> |
| | Sent by: |
| | curl-library-admin_at_lists.sour|
| | ceforge.net |
| | |
| | |
| | 01/17/2003 09:53 AM |
| | Please respond to |
| | curl-library |
| | |
|---------+---------------------------------------->
>----------------------------------------------------------------------------------------------------------|
  | |
  | To: libcurl Mailing list <curl-library_at_lists.sourceforge.net> |
  | cc: |
  | Subject: Re: lib curl nocopy callbacks |
>----------------------------------------------------------------------------------------------------------|

On Fri, 17 Jan 2003 RBramante_at_on.com wrote:

> There are times when I would like curl to send the request, parse all the
> response headers and get to the point where content is ready. Then it
> would be nice to have a way to get control of the socket directly and
> read/write on it without the overhead of the callback mechanism (and
would
> obviously eliminate the buffer copy during the content transfer).

Well, I can possibly see that someone would like something like this, and
I'll promise to read the suggestion once a more detailed one is posted! ;-)

The problem is of course that libcurl offers reading (and writing) of
different kinds of streams and it takes care of the underlying en/decoding
stuff (like HTTP-chunks, SSL, kerberos etc) and handing over the "raw"
socket
(in socket language it isn't raw) would then of course require the
application to get to know all those details to be able to work out the
data
accordingly.

Besides that, I guess working out a good API for this is the hardest part!
:-)

--
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en