On 2006-05-30, Daniel Stenberg wrote:
> On Tue, 30 May 2006, Daniel Moore wrote:
> >However ignoring multipart completely has what I see to be a pretty big
> libcurl ignores ALL content, not just "multipart". It has no knowledge of
> any content.
Well it depends on how you look at it. libcurl DOES look at fields in
the header to determine content length and encoding. That lets it to
undo compression/chunk encoding and to know when the response is over.
This means it also deals with the content - for sure, it doesn't care
WHAT it is, just how it's represented.
So I guess my point is that I'm thinking of multipart content and
particularly x-mixed-replace content as a representation of data
rather than data itself. I'm suggesting that libcurl could crack open
the multipart content and provide each individual part of content back
to the caller just like it does for an individual http request.
(see "Server Push" in http://wp.netscape.com/assist/net_sites/pushpull.html
for an explanation of where x-mixed-replace came from)
> 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?
For the example of a http camera, every time the camera grabs a frame, it
generats a new x-mixed-replace part and sends the frame. I'm suggesting
that it would be nice if libcurl returned each part individually,
thereby giving control back to the main program rather than remaining in
(here's a random webcam on the net which is using x-mixed-replace:
Now I know there's the multi stuff (although I haven't looked at it much
yet), and it's a cool facility that would let one implement the multipart
decoding as a consumer of libcurl. All I'm suggesting is that libcurl
could handle the details of cracking open the multipart (content-length,
boundaries, non-blocking io, buffering, callbacks etc - stuff it's already
good at) and supply each part individually through the libcurl_perform
Received on 2006-05-31