Branko Čibej <brane@xbc.nu> writes:
> Ben Collins-Sussman wrote:
>
> > * Proposed solution: place a hashtable within the auth_baton which
> > holds "runtime parameters".
> >
> > * create public functions to get/set "runtime parameter" values,
> > callable any time, by anyone.
> >
> > * provider implementations will look for specific runtime params
> > in the hash that they need; if not present, they simply
> > fail to return credentials (return NULL). (and obviously,
> > each provider will document what runtime params it needs.)
> >
> Don't go inventing yet another hash table for that, you can use an
> svn_config_t. Sure, you won't read it from a file, but it gives you all
> the interfaces you need, including a separate namespace for each
> provider's options.
Ah, interesting!
So instead of having to store hash keys like "svn:auth:certs:realm",
we could instead use an svn_config_t with a "svn:auth:certs" section,
containing a key "realm". Very nice.
I worried that there's no constructor function for an svn_config_t,
though. Looking at code, only svn_config_read seems to build one:
svn_config_t *cfg = apr_palloc (pool, sizeof (*cfg));
cfg->sections = apr_hash_make (pool);
cfg->pool = pool;
cfg->x_pool = svn_pool_create (pool);
cfg->x_values = FALSE;
cfg->tmp_key = svn_stringbuf_create ("", pool);
Should I put this code in a standalone constructor? I'm not even sure
I understand what all these fields are for.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 1 14:30:16 2003