On Tue, 30 May 2006, Daniel Moore wrote:

> I want to download a stream of jpegs from a HTTP camera. I've read previous
> emails on the lists indicating that libcurl just gives you the body of the
> stream, and at that point you're on your own. I can see why it works that
> way and I guess it's fair enough.

How else would it work?

> However ignoring multipart completely has what I see to be a pretty big
> disadvantage.

libcurl ignores ALL content, not just "multipart". It has no knowledge of any
content.

> Sure you can interpret the mime & content lengths and everything from the
> CURLOPT_WRITEFUNCTION and get what you want, but you have to decode the
> entire stream in the context of a single call to curl_easy_perform.

How else would it work? You get a stream passed to your callback. Your
callback gets the contents and decode it as it see fit.

> Which I guess is ok if you want the server push to drive your code dealing
> with each part, but I want to go the other way: grab each part with a call
> into curl - I can't call back out of curl (at least not very far).

I don't understand. How would you want to "back out of curl" ? If you want to
grab only a single part, why do you grab all parts? And if you want all parts,
why back out?

> Any thoughts on this issue? The individual parts of the mime stream are very
> like http responses in that they have their own header, content length and
> body. It couldn't be too hard to have curl (optionally) treat them as
> separate documents...

Perhaps not, but it would be very hard to see how such an approach would fit
into libcurl's content-agnostic way of living.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html