Re: Context parameter in public API

On Fri, Oct 11, 2002 at 11:32:18PM -0500, Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > It can be. If a library which has to be thread-safe wants to do
> > Subversion operations, it can't be sure that two instances of itself
> > don't do "startup time" stuff at the same time.
>
> What's wrong with two instances reading?

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));

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.

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.

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
    this wiki thing people keep talking about.

    IHNJ, IJLS "wiki".

    wiki. wiki. wiki.

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.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 12 19:10:50 2002