Justin Erenkrantz <jerenkrantz@apache.org> writes:
> No, no, no. Prompting provider should *not* be implementing a save
> function. Doing so completely violates the abstraction.
>
> This is why there are multiple credential types. A username/password
> credential is just that - two char*'s. Any provider should be able to
> save that pair.
These two paragraphs seem to be in contradiction to me. The prompting
provider should not save, and any provider of two char*'s should be
able to save that pair. But the prompting provider is a provider of
two char*'s... What am I missing? :-)
But in any case, the point is, we've been saving prompted auth data up
till now (except when no-auth-cache is explicitly requested), and
changing that behavior is outside the scope of issue #724.
If we implement orderings, and worse, try to give users control over
orderings and save-func preferences via the config file or something,
then we will spend many, many days of precious developer time
reworking what could have been a simple, comprehensible system. We
will have endless discussions about how exactly it should look; once
we have decided, it will be more complex to implement, *much* more
complex to document, and will force an extra query cycle into every
auth-related bug report we get:
"Thanks for the report. What is the order of your providers?"
"Sorry?"
"Uh, just show us your ~/.subversion/auth_providers..."
If we want to grow this feature, that's fine, but don't make it block
issue #724, which should be a no-op as far as behavior goes.
An API can always be changed, once we agree on what to change it to.
But this particular change should not happen before 1.0, if at all.
Morphing issue #724 to include this stuff is what some like to call an
"unfunded mandate". :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 19:23:01 2003