"SteveKing" <steveking@gmx.ch> writes:
> right now, subversion has one typedef for clients to
> prompt the user for information like username and
> password. This callback is used even for question
> like prompts ("accept certificate y/n").
>
> I suggest changing the existing typedef or adding
> some more:
>
> typedef svn_error_t*(* svn_client_prompt_t)(const char **info, const char
> *prompt, svn_boolean_t hide, void *baton, apr_pool_t *pool)
> typedef svn_error_t*(* svn_client_prompt_t)(const char **username, const
> char *promptusername, const char **password, const char * promptpassword,
> svn_boolean_t *store_auth_info, void *baton, apr_pool_t *pool)
> with that provider a GUI client could prompt for username/password in _one_
> dialog and also have a checkbox where the user can check if (s)he want's to
> store the authentication info or not (for that particular operation).
Gack. Steve, this is a very, very hard to read :-). Ben and I just
spent a long time scrutinizing it, trying to parse out its meaning.
Are you proposing two different alternatives to the current prompting
prototype above? Or is one of them the original, and the other the
new proposal? Or what? Don't make us look at the source code to find
the answer... :-)
Can you please, please use indentation, whitespace, capitalization,
and all the other techniques that people have evolved to convey
information in written form? It would help a *lot*.
a) Clearly separate pseudo-code from commentary, don't mosh them
together, forcing people to parse parens to find out where
the different sections begin and end.
b) Capitalize the starts of sentences. This makes them easier to find.
c) Align code as you would if it were in a source file. For
example, in your proposed new interfaces above, the parameters
could all be aligned in a column, then the eye could follow them
naturally.
d) Use patches of vertical or horizontal whitespace to separate
ideas. People depend on these to follow your meaning.
> typedef svn_error_t*(* svn_client_prompt_t)(const char *prompt,
> svn_boolean_t * answer, void *baton, apr_pool_t *pool)
> with such a provider subversion could ask questions like "accept ssl
> certificate?" and the client then can itself either
> add strings like (y/n) or buttons to the dialog - the answer (yes/no) would
> get returned to subversion as a boolean value.
Same here :-).
I'm not asking this out of some base need to make you conform. I'm
asking it because it's very hard to understand your mails. They take
longer to understand than they should, and it's hard to be sure if one
has understood them correctly even then.
As for the suggestions themselves, they seem quite good (if we are
understanding them correctly!). It sounds like:
1) You want to be able to retrieve more than one piece of
information in a single call to a prompt function. Instead of
taking a string and returning a string, it should take a list of
N strings and return a list of N strings. We anticipated that
this would be needed someday for GUI clients, and you're the
first person to need it. Can you file an enhancement request?
2) You want a prompting function that returns a boolean rather than
a string. Sounds totally reasonable. Furthemore, you want the
cert provider to use this new prompter. Sounds great.
Are we understanding correctly?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 1 20:50:21 2003