On Mon, 5 Dec 2011, Graeme Gill wrote:

> Sure. What are the (API) alternatives then ?
>
> Using a command line option to send a protocol specific command has two
> problems: it isn't applicable to a programmatic API; it doesn't encapsulate
> & hide the protocol specifics which is I think is most of the point of using
> a library like CURL.
>
> (ie. having different options to delete a file using HTTP, FTP and SFTP
> would seem to me to be a distinct problem in the current library.)

I agree that this is a dilemma that I have no good answer to. All the
protocols we support have different characterics and a different set of
commands.

* 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.

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. 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.

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

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html