Greg Stein <gstein@lyra.org> writes:
> > 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 thought of doing that, but providers have no way of communicating
with one another. If the third provider produces creds, there's no
way the 'caching' provider can know about them. The runtime-parameter
hash won't work as a means of communication, because then every
provider in the world needs to remember to put the creds in there.
> 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.
Why is that a problem? The worst thing that can happen is that the
cache is useless, so the first provider kicks in on the next retry.
If the cached creds are based on runtime params that changed between
different RA sessions, then the cache *should* fail, and the user
should be reprompted anyway.
> 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>"
Sorry, I'm totally lost, not understanding what you're talking about
anymore.
I already implemented the simple solution -- is it bad?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 16:34:25 2003