On 06/20/2017 10:15 PM, Andrew wrote:
> Daniel identifies three issues with the current API:
> * complicated (multitple varargs, several ways to do the same thing)
> * error-prone (due to the above)
> * the use of the public struct makes it hard to change - and yet
> hardly any users actually create the linked list of headers
> themselves!
>
> He suggests a new API where the form is an opaque handle that you get
> from curl_form_init, and then you call curl_form_addpart on the form
> handle to get a handle to a new part. Parts are populated with
> curl_form_set_name and curl_form_set_data.
>
I agree with the current form API problems: several years ago, I
submitted a patch to introduce a more general Mime handling API based on
handles, but it has been refused at this time (redirecting me to the use
of some external Mime library).

Since then, libcurl environment has changed:
* we have noticed the current form API limits and issues
* 3 more Mime-oriented protocols (SMTP, IMAP, POP) are supported

As we may now be ready to add new entry points for form handling, I
wonder if the new form API should not be extended to some more generic
API, capable of building a data stream from different components for any
Mime oriented protocol, reducing the need of some external Mime library
for calling applications. After all, forms are a subset of Mime. This
could probably be achieved without a too large "code bloat".

Patrick
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-06-21