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
