Justin Erenkrantz <jerenkrantz@apache.org> writes:
> In the end, you don't care which provider saved the credentials. It
> doesn't really matter. All you need to know is whether it was saved
> or not. You should be able to rely upon the fact that since it was
> saved, any subsequent retrievals should get that credential back. How
> it does it and what provider did it isn't important.
You and Sander believe that users should be able decide the
registration order of auth providers (which all understand the same
credentials.) This ordering determines not only the order of
retrieval attempts, but of storage attempts. And true -- if we give
users that control, then behavior isn't non-deterministic. Any broken
behaviors that result can be blamed on the user for ordering the
providers badly. And given a particular ordering, the behaviors can
be predicted ahead of time.
But let me point out: the main reason for writing the new libsvn_auth
architecture was so that we have an easy way to *add* new providers
(svn-agent, ~/.subversion/, client-side certs, etc.) Our short-term
strategy has always been to register all existing providers in a
single, fixed order within libsvn_client -- an ordering guaranteed to
work. When someone writes a new provider, we slip it into our fixed
ordering.
But now you and Sander are trying to add a new "dynamic ordering"
feature. Yes, libsvn_auth *does* set us up for this feature, but it's
not something we can casually slip in. First, it's a huge amount of
work: it means a writing a new ordering API, creating a (run-time?)
mechanism that allows users to choose ordering, implementing a default
ordering, and writing new user documentation. Second, it gives users
a huge opportunity to shoot themselves in the foot, and makes svn hard
to debug.
Karl and I aren't convinced that users need this feature, at least not
now, and we're definitely not persuaded we need to spend any pre-1.0
time on it. We don't have this flexibility right now, and I've not
heard *anyone* asking for it. I'm thinking it should be filed as a
post-1.0 feature request.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 18:34:11 2003