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

Ben Collins-Sussman <sussman@collab.net> writes:

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

I think I get it now.

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

It's not the choice I would have made. The core svn code knows about
the parameters so I would put them in a structure. It could be an
opaque structure with accessors if you want to get the same amount of
interface isolation.

Now that I think about it, there is very little to choose between the
two approaches. At the moment the hash keys are part of the public
interface. We could have type safety by replacing

  #define SVN_AUTH_PARAM_FOO SVN_AUTH_PARAM_PREFIX "foo"

with

  void svn_auth_param_set_foo(apr_hash_t *hash, const char *);
  const char * svn_auth_param_get_foo(apr_hash_t *hash);

Then it's a small step to

  typedef struct svn_auth_parameters_t svn_auth_parameters_t;

  void svn_auth_param_set_foo(svn_auth_parameters_t *params, const char *);
  const char * svn_auth_param_get_foo(const svn_auth_parameters_t *params);

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org