Re: Suppresion of password prompt

[Graham Shaw]

In article <address@hidden>,
   Simon Josefsson <address@hidden> wrote:
> Graham Shaw <address@hidden> writes:

> I can think of two easy solutions:

> 1) Add a new Shishi_tkts_hintflags flag such as
> SHISHI_TKTSHINTFLAGS_NON_INTERACTIVE which inhibits all password
> queries.  We probably need a new error code to signal that the command
> failed for this reason.

> 2) Add a callback interface for dealing with password queries.  This
> allows you to get a callback when a password is needed.  The callback
> could fail (which presumably it would in a non-interactive situation).
> We probably need to add the same error code here as well.

> Can you think of something else that would solve your problem better?
> Which do you prefer?  I could implement both, they both seem useful.

Either would fully solve my current problem, so from a personal POV I
don't have any preference.

The first would be marginally easier to use, but I think the difference is
small.  You could narrow the gap by implementing the non-interactive
version of the callback as part of the library, so that the user doesn't
have to - that way it would be one line of code either way.  (If you did
that then I don't think there would be any advantage in having the flag
too, because it would be so easy to achieve the same effect with the
callback.)

The second looks like the more general solution.  I'm not sure it lets you
do anything that you couldn't by calling the first one twice, but it
probably has the edge in terms of elegance and efficiency.

The second solution imposes a small cost on everyone by increasing the
size of the hints structure.  Probably negligible, because I can't imagine
why you ever need more than one or two instances.

With thanks,

-- 
Graham Shaw (http://www.riscpkg.org/~gdshaw/)
The RISC OS Packaging Project (http://www.riscpkg.org/)
The RISC OS Toolkit (http://rtk.riscos.org.uk/)