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:

> Now if the core, generic code is to add these parameters to the
> hash, it needs to know which key to use and what form the value
> takes (string, integer, etc.). I don't see why this is more yucky
> than adding those same parameters to a structure, where the element
> name (the hash key) and the element type (the form of the hash
> value) can be checked by the compiler.

Hmm, that's a good point. By stuffing all runtime parameters into a
psuedo-global hash as void * pointers, we're losing type-checking.
Hmmm. Not so good.

> [...] assume that for some reason I cannot use my provider specific
> code to add the realm to the hash. [Note: when I say "add to the
> hash" I just mean "pass the parameter", as I said, I would put it
> straight into the provider baton rather than add it to the hash.]

Alas, I think your dream of putting the realm-data directly into the
provider's baton will never work. It would mean that a pointer to the
provider baton would somehow have to be propogated all the way down
through code, probably to some RA layer receiving the auth challenge.
We don't want to propogate every provider baton into RA code!

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

In the current design, the way to implement a new auth provider is
this:

   1. write a provider that wants certain input data, and returns
      certain credentials based on the data.

   2. find some place in the "core" svn code that receives the input
      data, and implicitly pass the data to the provider via the auth_baton.

          example1: only svn_client__open_ra_session() has the directory
          path containing cached username/password.

          example2: libsvn_ra_dav contains neon callbacks that
          receive 'challenge' data (like realms.)

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.

Rather than propogate every single provider's baton down into various
places in svn core code, we just propogate the auth_baton. We give
input data to providers by changing something in the auth_baton, and
providers query the auth_baton for the data they need. It's an
indirect system.

So the only debate here is whether the auth_baton should contain a
hash or a big C structure.

> It's not a "Union of All Possible Runtime Values Not Known At Startup,
> For All Possible Providers". It only includes those parameters that
> the core, generic Subversion code understands.

But those are *exactly* the same things.

  "set of parameters that svn core code is forced to understand"
     == "Union of all possible runtime values not known at startup,
         for all possible providers"

See?

Here's my only argument for using a hash instead of a structure:

My worry is that every time somebody wants to write a new provider,
they're going to have to add a field to this public, transparent C
structure, which will do wacky things API wise. Stuffing void *'s
into a hash loses type checking, but doesn't break APIs either.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 03:42:56 2003