Re: about context parameter

[I've been meaning to respond to this for some time...]

Greg Stein <gstein@lyra.org> writes:

> I believe we should have something like svn_client_t. That object would be
> opaque and could hold a number of things:
>
> * auth info
> * config info
> * notification funcs?
>
> It should be documented that it is totally fine to mix and match
> svn_client_t structures in case a person wants to use different notification
> functions, for example. To make it apparent that we aren't storing state in
> the context (thus, they can be mixed/matched), we might actually want to
> make the structure non-opaque.

I'm not sure svn_client_t is a good name, I don't think this is part
of the client library, is it? We don't want the lower level libraries
to have to depend on libsvn_client. Perhaps svn_environment_t, or
svn_context_t, or even svn_t would be better. I'll use svn_client_t
in what follows, but that's just for convenience.

How exactly do you see this working? I assume the svn_client_t object
gets passed from the application down to the lower levels, such as
ra_dav, where it can be used to obtain certain information. If the
type is opaque what does the ra_dav code look like? Is it like this

   svn_error_t *ra_dav_foo (svn_client_t *context)
   {
     int n;
     SVN_ERR (svn_context_get_yyy (&n, context));
   }

If so, then how will an application be able to provide it's own
implementation of a context retrieval function? It would appear to
need something like

   svn_error_t *
   svn_context_register_get_yyy(svn_client_t *context,
                                svn_error_t *(*fn)(int *, void *),
                                void *fn_baton);

which stores fn/fn_baton in the context object, so that a later call
to svn_context_get_yyy can call fn and pass fn_baton.

It may be simpler to have a non-opaque object, a vtable/baton
combination

   typedef struct svn_client_t {
     svn_error_t *get_yyy(int *, void *);
     svn_error_t *get_zzz(const char **, void *);
     void *baton;
   } svn_environment_t;

and have the ra_dav code look like

   svn_error_t *ra_dav_foo (svn_client_t *context)
   {
     int n;
     SVN_ERR (context->get_yyy (&n, context->baton));
   }

Subversion would provide a generic

   svn_client_t *svn_context_create();

and the application is free to substitute any of the vtable functions.

The svn_client_t could also contain cancellation information, this
could either be another function pointer, or it could be a data
pointer. The latter would provide a cancellation mechanism without
the overhead of a function call, which could be important if the check
goes into SVN_ERR. We could even have both a function pointer and a
data pointer and so let the application decide which to use.

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