On 06/22/2017 09:19 AM, Patrick Monnerat via curl-library wrote:
> On 06/22/2017 12:20 AM, Daniel Stenberg wrote:
> The form API would need to become a much more generic MIME API for it
>> to work good for that. But sure, if someone has use cases in mind and
>> want to suggest how the current form API redesign proposal can be made
>> into a more generic MIME one, then I could be interested.
> Having a mean to get a handle for each subpart could be an elegant way
> of doing that. I'll investigate for some proposal.

What about a curl_form_subparts(part, form) function ? To support
multipart MIME, it could be used as:

|curl_form *form = curl_form_init(); curl_formpart *part =
curl_form_addpart(form); curl_form *subform = curl_form_init();
curl_formpart *subpart = curl_form_addpart(subform);
curl_form_name(subpart, "name", -1); curl_form_data(subpart, "Daniel",
-1); curl_form_subparts(part, subform); |

Also, the wiki note about encoding should be reinvestigated: chunked
encoding has no sense for SMTP/IMAP and in this cases should rather be
replaced by quoted-printable or base64. This is mainly "internal
cooking", unless we want the caller to have control on it.

Finally, if we decide to implement it that way, should'nt the API naming
be "curl_mime_xxx" ? This has the advantage of enphasizing the
difference with the old API.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-07-16