[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: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2003-01-31 19:37:43 CET

--On Friday, January 31, 2003 11:30 AM -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:

> 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

It doesn't necessarily have to be the users, but the *client* should
be in control of the ordering. If the client wishes to allow the
users to manipulate the ordering, that's fine. But, that's not
libsvn_auth's problem. In fact, most of the hooks in httpd are not
allowed to be rearranged by the user.

Your solution breaks down when we consider that I might want to have
a different client with a different ordering. By making the
ordering explicit, it becomes easy to do that. Relying upon when
things get inserted may be iffy.

libsvn_client shouldn't be doing the ordering. The svn client code
should be doing the ordering.

To be clear:

svn_auth_register_provider("AGENT", FIRST...)
svn_auth_register_provider("DISK", MIDDLE...)
svn_auth_register_provider("PROMPT", LAST...)

Relying on implicit ordering is dangerous, and as you have realized
it makes it *really* hard to implement the save semantics cleanly.
You are making it impossible for save to work correctly if you don't
allow all providers to have a chance to save.

> 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.

And, I'll reiterate that this has the same design flaw as the ra
ordering. It is impossible to 'drop in' a new RA layer without
modifying libsvn_ra. I'd hope that the auth providers don't have
this same problem. Hence, they need to be able to register
themselves with explicit ordering.

But, let me point out: implementing a prompt provider with a save
function is broken. If it is a matter of having me go in and tweak
libsvn_auth myself, I volunteer. =) -- justin

---------------------------------------------------------------------
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:38:29 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.