On Sun, 9 Feb 2014, Steve Holme wrote:

> * If a username is specified in each separate operation but no password (for
> either the host or proxy), the user will be asked for the password in each
> operation as they take place. Should this be performed up front before the
> first operation is called? Currently this takes place in operate_do() but
> could be moved to operate() just after the parsing of the command line
> arguments.

I think a user would appreciate getting them all up front (unless it makes the
code very akweard). The transfers may be slow so there will be cases where
entering passwords first and then let the command sit there and work can be
useful.

> * Should the prompt for this password differentiate each host rather than
> prompting "Enter host password for user 'Abc':" or "Enter proxy password for
> user 'Xyz':" ?

Host may be a bit tricky since the tool doesn't extract host name, but then we
also can't know on what basis user have different passwords. They can just as
easily have different passwords for different paths or just for different
contents sent to a URL... Perhaps simply refer to URLs by number? "enter host
password for user 'Abc' for URL #7:" ?

> * The initialisation and clean-up of libcurl source code generation still
> takes place in operate_do() as this is the old operate() function.
> Technically it is possible to specify this on each operation but should
> probably be more of a global option with the initialisation being moved to
> the new operate() function. Should we introduce global options that apply to
> all operations for options like this?

There are a bunch of command line options that we probably want to have
"global" effect. Like --libcurl and even -v / --trace* ...

> * I have removed the curl handle freeing from operate_do() as a) This would
> destroy the handle after the first operation for any further operations and
> b) It was already being performed in config_free_fields(). From my own
> testing I don't see any problem with this, but the comment that was in there
> has me a little worried. So, does the curl easy handle need to be destroyed
> whilst the progress bar variable is still in scope? If so, can I move the
> progress bar to be a single instance across all operations by making it
> again part of operate() which would then be passed down to operate_do() ?

I'm afraid a bit lost about the exact place and variable you talk of, but from
what I can see you're right.

> * Do we need to reset certain curl_easy_setopt() options after each
> operation? For example if the user specifies a custom request with -X on the
> first operation then it will be inherited on the second if it is not
> overridden. Note: Both Test 815 and 816 overwrite it in the second
> operation. However, we don't currently have a way to set it back to NULL.

Yes we most probably do. If each "section" is separate it shouldn't be
affected on the previous options. Or else we need to document those clearly.

> * How should we document the separating ":" character in --help? It doesn't
> feel right to mention it in the options but I can't think of the best format
> to use if we mention it in the usage line.'

It was discussed previously and I think I agree that ":" is not a good
separator to start with.

I think I would prefer that we use a command-line look-alike. Perhaps --next
or --wall or something like that. Possibly we can have that as a short option
too and then we could consider "-:".

> * Where is the best place to mention the separator character in the man
> pages?

If we make the syntax to be like other options we can probably just add it in
the man page like any other option.

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