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

Philip Martin <philip@codematters.co.uk> writes:

> As far as I can see the hash contains two kinds of keys, there are
> those known at registration time and those that are not.

Correct.

> The items known at registration time are "fixed" they don't depend
> on the context of the call and could be passed directly to the
> registration routines.

Absolutely. The provider "constructors" could take these fixed
runtime parameters. That would work fine.

> [...] The other items must be understood by the core, generic
> Subversion code and may depend on the context of the call, these
> could be passed via a normal C structure. The access baton is an
> example of variable item.

Yes, we could do that. But now we're back to the idea of the Giant C
Structure which contains the "Union of All Possible Runtime Values Not
Known At Startup, For All Possible Providers". And Brane has already
explained why that's a yucky thing. Do you not agree it's yucky?

> It boils down to this: the hash should be replaced by a structure of
> the things that the core, generic code knows about. Everything else
> gets passed at registration. Is the certs "realm" really something
> that doesn't fit either of these categories?

No, the certs realm is in the latter category: "those things that are
not known at registration time". When neon receives a certs challenge
from the server, it passes the server-specific information (such a
"realm", etc.) into a callback. The callback then places the info
into the auth_baton hash (or into the Giant C structure), and then
calls svn_auth_first_credentials(auth_baton, SVN_AUTH_CRED_CLIENT_CERT).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 02:23:07 2003