Hello,

Patrick Monnerat wrote:

> > I see a lot of code added with very little gain for the majority of
> libcurl users.
> > At the same time, I can see how most of this can be done pretty
> similarly with little loss at a layer outside of libcurl.
>
> I agree: since the true libcurl integration is not yet done, code might
> look as duplicated. For this reason, integration could slim down
> existing code. Up to now, code intermixing mainly consists in reusing
> the curl_slist structure and some internal procedures and data like
> base64, boundary generation and hash table.
>
> > So if there's no additional pros or people standing up for the
> greatness of this idea, I'm sorry to say that I'm against it.
>
> I'll wait for some other reaction until next week, then if none or
> negative, I'll dissociate the MIME handler from libcurl. In this case,
> I'll carry on working on it as a separate library because we (my
> company) really need it, but I'm afraid to say this would'nt be
> opensourced (company policy).
>
> I'm sure there are lots of SOAP users that have renounced on using
> libcurl because of the lack of a MIME parser.
>
> If some other list readers have some interest on it, this is the time to
> say so !!!

Your MIME parser would have greatly interested me two years ago, but now I
have made other choices.
I can just detail a bit the choices I made, in case this can help you.

I needed also to support "SOAP with attachments" (SWA),
and found almost no MIME component matching my needs.
My need was both on client side (cURL) and server side (apache httpd), so
something tight inside cURL would not have helped.
My final choice was:
- to use GMime (http://spruce.sourceforge.net/gmime/):
        - pros: LGPL license, complete MIME support, coded in C, says it
support S/MIME (I never tried S/MIME even if it was an initial
requirement),
        and should be quite reliable if integrated in Gnome email readers.
        - cons: depends on Gnome libraries, and poor diagnostic features
for erroneous input (at least in V2.1).
- to integrate GMime with Apache httpd API, to parse SWA messages in my
apache module
- to design a SOAP interface without multipart answers, so I did not need
to integrate cURL and GMime...
  I think this would not be difficult, based on my experience with apache
integration.
- I made a few changes inside GMime to avoid to extract parts in files
rather than in memory. Never found time to send changes to the author.

I also used cURL internal features about HTTP forms to build SOAP
multipart messages,
but this was only in a unitary test context: I am not sure
other SWA parsers would ignore extra MIME headers or parameters dedicated
to forms.

Note I never got trouble with Gnome libraries needed by GMime:
I compiled and linked them, and then forgot them.

This work was within SOAP 1.1 context, not SOAP 1.2.

Best regards,
Yves Lejeune.
Received on 2008-08-07