Re: authentication cache

On Thu, Feb 20, 2003 at 12:51:37PM -0800, Ben Collins-Sussman wrote:
>...
> Heh, this isn't a bug, it's just a libsvn_auth design oversight.

Nope. See below.

> Our main commandline client:
>
> creates a ctx object
> creates an auth_baton with various providers
> runs a single subcommand
> calls first_creds, next_creds, next_creds ...
> exits
>
> There's simply no caching design here at all, which would be needed by
> long-running GUI clients.
>
> What's happening with a GUI client is this:
>
> creates a ctx object
> creates an auth_baton with various providers
> run many subcommands
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> exits
>
> I think the solution here is simple: the auth_baton can cache the last
> returned set of credentials (of each type). Then we change first_creds()
> to always return the cache, if available. Pretty easy.

Instead, the GUI can create an in-memory caching provider. I don't think
that it should be built into the auth system, especially given that any
particular set of credentials returned could be arbitrarily keyed by
parameters that were set at runtime.

Currently, the auth interface has this "out of band" global-variable-like
thing where you set runtime parameters. That API makes a lot of sense for
configuration type stuff (e.g. the cmdline switches), but less sense for
true runtime params. For those, you would ideally have a hash that is passed
specifically to first_creds. Then it becomes obvious that your credential
fetching has additional inputs beyond "give me some of <these>"

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org