Dan Fandrich wrote:
> > All the examples I have seen on the website use callback functions
> > and intermediate buffers, which I would ideally like to avoid (and
> > keep the memory footprint down). While having a buffer would help
> > with network stalls, reading MPEG Audio directly from the network
> > socket has always worked quite well in mpg123.
>
> This paradigm doesn't quite match libcurl's as the latter expects to
> perform all the low-level grunt transfer work itself. This allows it to
> handle compression, chunked transfers, and encryption itself and avoid
> burdening the application with knowledge of all those areas. The mpg123
> situation where it reads raw data directly from a descriptor only works if
> the data is not encoded in any way. If you want any of libcurl's data
> transformation options, then the raw descriptor approach will fail.

Besides, if mpg123 reads directly from the network, it won't get https
which Dan said is one of the reasons for using curl.

For the case where the data connection is not encrypted or compressed
(but could be chunked), is it not possible for curl to read most of
the data directly from the socket into application-supplied buffers?

The other cases, and the boundaries, would transform from the raw data
to the application buffer as usual.

-- Jamie
Received on 2006-10-20