cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl the next few years

From: Dan Fandrich <dan_at_coneharvesters.com>
Date: Thu, 19 Jun 2014 21:16:22 +0200

On Thu, Jun 19, 2014 at 02:24:40PM +0200, Daniel Stenberg wrote:
> Improve
> =======
>
> 2. curl -h output (considered overwhelming to users)

I've thought this for a while as well. My thought was to replace the --help
output with just the basic options, and create new help options based on
categories, like --help-auth, --help-proxy, --help-connect, --help-crypto,
--help-xfer, --help-misc and probably --help-http, --help-ftp and --help-all.
Or, split based on protocol, so --help-smtp would show every option that
applies to SMTP transfers, --help-ftp for FTP transfers. There would be plenty
of overlap between them if done this way, but it wouldn't be sufficient if the
goal is reducing general user overload. This could even be done at the same
time as the category options to provide multiple ways to categorize and find
them.

Documenting these options in curl.1 in sections would also be a good idea.

> 3. we have > 160 command line options, is there a way to redo things to
> simplify or improve the situation as we are likely to keep adding
> features/options in the future too

There are more than 210 libcurl options, so curl should probably be gaining
some more :^) Seriously, curl/libcurl is a powerful tool and I don't think we
should be dumbing it down for this reason. But, just dumping the options into
--help and expecting users to find them there isn't going to scale any longer
(and probably realistically stopped scaling 5 years ago).

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-06-19