[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc libsvn_client libsvn_auth

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-01-31 18:30:55 CET

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.