Re: Can't make bonobo work



> I think you are partially right, the solution may be a mix of the two
> solutions because:
> * there are some controls which are common enough between providers
>   to make only one control for all (I think of tables manipulation
>   for example)
> * there are some controls which adress an element which has a lot
>   of differences from one provider to the other (think of users
>   management for which each provider has its philosophy, or of the
>   sequences elements which appear very different from one provider
>   to the other.
> 
> So the solution I propose is:
> * we create default minimum common controls for all the providers on
>   as much elements as possible (tables, views, and even users), but these
>   controls WILL NOT have all the features that a particular provider
>   offers.
> * If a provider maintainer finds that the control for a provider does not
>   offer enough possibilities (or if the control does not exist), he can 
>   write another one more adapted to the provider.
> * we provide a way for a client application to get the right control
>   depending on the name of the connection, and on what is installed
>   in the OAF 'realm'. Maybe for this we could use the new query mechanism
>   provided by OAF.
> 
ok I agree. We can make the "automatic" activation by making use of the
repo_ids.
That is, we can have all these config controls implement the
IDL:BonoboControl/gnome-db-config-component:1.0, then the specific parts
of the config stuff (IDL:...gnome-db-config-{users,db...}). This for the
generic components, but for provider-specific, we can  have
IDL:BonoboControl/gda-postgres-config, etc.

Thus, client apps can first try to activate the provider specific
component,
and if not found, load the generic one.

This naming stuff hasn't been thought well, so don't believe it as
carved
in stone, but it's just an idea on how we can make things work.

> Anyway, I still think it is good for an application to get only one control
> if it whishes (and also all of them for one connection is possible). What
> I did in gASQL is add a menu to run gnomedb-mgr if the user wants to
> manage all the connections, ... in a single way (that will be in V0.5.5).
>
BTW, I'm converting the gnomedb-mgr app to a component, which you'll be
able
to embed in gASQL directly. I'll commit this soon.
 
cheers





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]