Daniel Stenberg wrote:

> * I don't believe in inventing new URL formats since they are actually
> supposed to be used similarly all over in different programs and
> environments. I know I've already violated this point but I still like is to
> remain conservative.
>
> * I don't believe in inventing new CURLOPT_* options for each and every sub
> command that a protocol can provide. It would quickly grow the amount of
> options a lot, even if some of the commands would be possible to re-use
> between protocols.

Yet the latter seems to be the Curl standard way - see
<http://curl.haxx.se/libcurl/c/curl_easy_perform.html>

"Just note that you will have to use curl_easy_setopt(3) between the invokes to set
 options for the following curl_easy_perform."

While it's easy enough to come up with some new API such as a "perform_with_modifier",
I wonder if it would just increase confusion, and it's not clear to me how it
would interact with curl_multi_perform() etc., and at the end of the day is
simply a different slot to provide an option that could be set with the current API.

> As I see it, we basically have no other way to support a number of custom commands than providing
> them in a list.
>
> If we would like the commands to be generic between protocols, we would have to translate them for
> each target protocol and we would have multiple commands that the protcol can't do.

There's nothing unusual in that though. Make what's common between protocols
use common API elements, and what's unique between protocols use unique API elements.

If several protocols have a similar concept of "list", "delete" etc., then having
a common way of selecting this reduced cognitive load, eases usage and reduces
mistakes. Isn't this what's going on with CURLOPT_USE_SSL etc. ?

Ideally list what protocols each option applies to (or create a table) in the documentation.
[Saves having to grep the source.]

> Also, as we
> currently don't interpret the commands at all, a user of libcurl can pass in FTP commands to a
> server that is entirely custom or non-standard.

Sure, such options are valuable, but why should the user of the API have to know
the minutia of each protocol to do high level things like list or delete ?

> If you have an idea that is better than what we currently have, then by all means let us know!

I'm not sure that attempting to turn the current API upside-down is really justified
for the purpose of adding a couple of common options. The "curl way" seems very much
to be to use curl_easy_setopt/curl_multi_setopt, so CURLOPT_DIRLISTONLY and
CURLOPT_DELETE seem perfectly consistent, even if they are a little clunky because
you typically have to turn then on then off.
[If the latter is really a major irritation, then perhaps the idea of having a
 "one shot" setopt would be an approach to addressing this.]

Graeme Gill.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-06