On Sat, Oct 12, 2002 at 01:02:57PM -0400, mark benedetto king wrote:
>...
> My feeling is that the config reading is not done at the right level
> of abstraction. It should be read once, by the consumer of the
> libsvn_client API.
>
> Something like, for example:
>
> svn_client_t *client;
> svn_config_t *config;
>
> SVN_ERR(svn_config_read_config(&config, pool));
> SVN_ERR(svn_client_create(&client, config, pool));
Yup. You could also argue for a reversal. The config reader updates the
client object. Not sure that I have an opinion either way, tho.
> It would be Nice(TM) if the relationship between
> the configuration and the command-line switches were
> formalized. Something like this, in main.c:
>
> SVN_ERR(svn_config_read_config(&config, pool));
>
> SVN_ERR(svn_cl__apply_options(&config,
> os,
> svn_cl__option_config_mapping_table,
> pool));
>
> SVN_ERR(svn_client_create(&client, config, pool));
>
> Obviously, that would be UI-specific.
Yes, that would be quite nice.
> Why does config need to be pulled out of the internals and
> passed along in a client context instead?
>
>
> 1.) Different clients might be configured differently.
> $HOME/.subversion is really fairly unix-command-line centric.
>
> In the near future I suspect we'll see lots of different
> configuration/preferences database/registries, including
> GNOME, KDE, Win32, etc.
Yup!
> 2.) Some applications may need to support multiple concurrent
> configuration. The only one that comes to mind immediately
> would be a svn-backed application that supported multiple
> concurrent users, each with their own preferences. Maybe
A bit harder to argue, but the APIs should *not* prevent one application
from "instantiating" SVN with different configs. Thus, a global config would
be big suckage.
> this wiki thing people keep talking about.
Yup. To be concreate, let's say that some app is written in, say,
mod_python. That app loads a config when a request comes in, and uses it to
satisfy the operation. But woah! There is *another* thread doing the same
thing. Each thread wants their own configuration.
Globals are evil. Not just for thread *safety*, but for partitioning
operation from one thread to another.
>...
> 3.) A client context that contains the configuration "feature-proofs"
> the existing APIs (actually, we'd probably wind up *removing*
> parameters from them). Right now, most simple command-line changes
> require the addition of parameters through three or more layers of
> APIs. If we want to freeze these APIs (and svn_client_* is definitely
> an API we'd like to freeze) I think it's *critical* that we put
> this support in sooner rather than later.
Yup. This problem is also why I suggested (and will finish one day) the
libsvn_auth stuff. It would allow for changes in auth systems and mechanisms
without reflecting those changes throughout the whole codebase. The client
API is very similar. "oop! need notification. let's add it to the whole
system."
We just need to be *really* careful that we don't start lumping all kinds of
crap into the structure. If there is any possibility that two calls will
need to be made to a given API, and the calls will have different params,
then we don't want to embed those params into the structure.
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
Received on Sun Oct 13 09:12:02 2002