You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2003/02/01 03:25:54 UTC
Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc
libsvn_client libsvn_auth
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.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc
libsvn_client libsvn_auth
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Branko Čibej <br...@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.
>
>
(Those fields are documented in config_impl.h). Yes, factoring that code
into a separate constructor would be fine. In fact, I seem to recall I
_had_ such a constructor at one time, but someone (Karl?) threw it out
on the grounds that it "complicated the interface." Well, duh.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc libsvn_client libsvn_auth
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@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
Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc
libsvn_client libsvn_auth
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Sat, Feb 01, 2003 at 04:25:54AM +0100, Branko Cibej wrote:
>
>
>>..
>>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.
>>
>>
>
>Euh... apr_hash_t ??!!
>
>We aren't about to code up a new hash table implementation. I don't think an
>svn_config_t feels right. This isn't about configuration. It is about
>storing values from an auth challenge, or storing the WC dir where cached
>auth data can be found.
>
>
Of course it's about configuration. Not runtime configuration for the
client, but config data for the auth providers. And svn_config_t is a
layer on top of apr_hash_t. The nice thing about svn_config_t is that it
has a two-layered namespace (sections and options), and a fairly simple
interface.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 4685 - in trunk/subversion: include libsvn_wc libsvn_client libsvn_auth
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 01, 2003 at 04:25:54AM +0100, Branko Cibej wrote:
>..
> 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.
Euh... apr_hash_t ??!!
We aren't about to code up a new hash table implementation. I don't think an
svn_config_t feels right. This isn't about configuration. It is about
storing values from an auth challenge, or storing the WC dir where cached
auth data can be found.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org