prompting providers

[SteveKing <st...@gmx.ch>]

Hi,

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

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.

right now GUI clients show a dialog box with the question and the user then
enters 'y' or 'n' into an editbox. This looks ugly 'cause the user is used
to just 'click' yes or no and not used to enter 'y' or 'n'. Sure the client
could provide that by simply returning 'y' if the user clicks the
yes-button, but that would mean hard-coding the answer and it will break as
soon as subversion supports multiple languages.

Stefan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: prompting providers

[SteveKing <st...@gmx.ch>]

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

Sorry. I'll try better next time.

> 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?
Yes, you got it right. But for the username/pw provider I suggest
a prompt function which takes two strings, returns two strings and 
a boolean. The boolean would indicate if the information should
be stored or not (SVN_CONFIG_OPTION_STORE_PASSWORD).

>    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.
Yes, exactly. Maybe instead of a boolean an enum type could also
be used, e.g. for YES/NO/CANCEL/YESTOALL, ...

> Are we understanding correctly?
Yes! And even my mail was such a mess :)

Stefan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: prompting providers

[kf...@collab.net]

"SteveKing" <st...@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