David Waite <mass@akuma.org> writes:
> The only dependancy the existing providers have have on neon is the
> set of failure flags passed in to the server cert validator. The
> prompting providers will rely on pulling the (neon-parsed) certificate
> structure out of the auth baton hash. Neither one of these should be a
> runtime dependancy.
I think our final goal is this:
* libsvn_ra_dav is the only library dependent on neon.
*theoretically*, it may not be compiled at all: no ra_dav, no neon.
It's perfectly fine for a client (cmdline, gui, etc) to pick and
choose which RA layers are built and loaded via DSO.
* the neon cert callbacks are defined in libsvn_ra_dav, obviously,
since they depend on neon.
* the cert *providers* are defined in libsvn_client, making them
usable by any client, and any RA layer.
* the cert providers shouldn't depend on neon, since ra_dav may not
exist. they should define the credentials they return as
abstractly as possible: "path to a client cert file",
"passphrase to unlock a cert", or "server cert errors we can
ignore".
Does that make sense, David? Do you think you can migrate the
providers into libsvn_client and then redefine the server-cert error
codes in svn itself (svn_error_codes.h)? You'd simply have your neon
callback 'map' the neon error codes to svn error codes.
Ultimately, gstein and I have been discussing doing away with
libsvn_auth altogether: the library, that is. The library has only a
single C file with provider registration and looping logic... so we'll
probably end up moving that C file into libsvn_subr, and toss
libsvn_auth. svn_auth.h won't change a bit.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 18:06:02 2003