Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos

On Wed, Feb 26, 2003 at 08:41:45PM -0800, Ben Collins-Sussman wrote:
> Philip Martin <philip@codematters.co.uk> writes:
>...
> > If the provider specific code cannot do it, then the core, generic
> > code must do it. That means the core, generic code needs to
> > understand realms explicitly.
>
> Right. True. These are all assumptions behind the current
> libsvn_auth design.
>...
> So the truth here is that it's usually impossible to write a "totally
> separated" provider; unless your provider knows *all* the input data
> from the very beginning, step #2 means making core svn code --
> somewhere -- aware of the provider's specific needs.

Careful. You *can* write a totally separate provider IFF it uses existing
inputs. This is how the caching or prompting providers work. I can go and
write a new prompt provider that tosses up a curses-based dialog if I want.
No changes anywhere but the app when the new bugger gets installed.

The "problem" comes up when you want to write a provider that requires new
types of input. Something has to provide those, and that something
(currently) is usually an RA layer.

But note that I could go and write a new RA layer to send commits as
GPG-signed emails, and a new provider to ask for the password to GPG to have
it sign the email. No changes anywhere in the system, except for the app
when it registers the new provider and a change to libsvn_ra to know about
the new RA layer. Specifically, no change to any kind of core C structure
that is used for passing parameters about.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org