Phil Blundell wrote:

> You have spoken about code sharing but the sections of code that are
going to be shared seem to be small

I expect to simplify drastically the formadd.c file during integration,
at least on the MIME generation procedures. We still have to preserve
some of its code, to emulate the present formadd feature.

> To be honest it never really occurred to me that MIME parsing should
be libcurl's responsibility, any more than I expected it to include an
XML parser or an HTTP server.

MIME is just another protocol layer, inserted between those supported by
libcurl and some embedded data. Now you can process these embedded data
directly (this is i.e.: XML parsing and such), providing they are not
MIME-packaged. As soon as there is a MIME layer, you're blocked unless
you have such a parser. In addition, a MIME layer is not limited to the
only HTTP protocol. But even in the HTTP case, automated processings
like those performed with libcurl tend to use MIME more and more.
Originally no protocols were libcurl's responsibility, but each protocol
addition is a big asset.

> Indeed, if I hadn't used libcurl I would probably have found myself
needing to write an HTTP client as well, which would have been even
worse.

For the SOAP particular case (which in significant), there are other
specific products (i.e.: like gsoap) that support HTTP client and MIME,
but my intention is to have something more generic.

> But I really do struggle to see how it is a natural fit as part of
libcurl.

As natural as the formadd feature can be, but a bit more "modern" :-)

Many thanks for your comments,
Patrick
Received on 2008-08-07