Re: Can't make bonobo work

[Vivien Malerba <malerba gears linuxave net>]

On Wed, Oct 11, 2000 at 05:57:05PM +0200, rodrigo linuxave net wrote:
> > Hi all!
> >
> > I've installed gnome-db V0.1.0 (along with OAF 0.5.1, bonobo 0.18) and
> > can't have the gnome-db bonobo controls work. All I get is a message
> > from
> > OAF saying:
> > ** WARNING **: Could not load
> > OAFIID:control:gda-postgres-users-list:b04e9dc2-1cc8-4027-8cf9-27dcb6a2a63f
> >
> > and errors because of inexistant properties (which is normal
> > considering
> > that there is then no bonobo control).
> >
> > The OAFIID is mentionned correctly in the gda-postgres.oafinfo and
> > the connection to the postgres provider works OK.
> >
> >
> yes, we've got a problem I forgot to tell you when I made the separation
> between gnome-db and libgda, which is that the providers' Bonobo
> controls were not copied from the old module. This was because I was not
> sure if they should go in libgda (and built only if bonobo was found,
> and made in a separated package), or in gnome-db, which will mean having
> gnome-db "depend" on all the DBMS supported in libgda.
> 
> So I forgot to say it, and since then, I have forgotten about it. The
> code is still in cvs, under the gnome-db-old module.
> 

Yes, I realised that after posting my message. My bet would be to put
the bonobo controls with gnome-db since they use GTK/GNOME technology.

> But recently I had an idea, which is to use the current schema
> constraints to do DDL stuff, that is, as we can right now get a list of
> users, tables, fields in a table, etc, we can have a function
> (gda_connection_modify_schema) which will get a variable number of
> schema constraints as parameters, and depending on them,
> create/remove/modify a user, a table, etc.
> 
> The latter will mean dropping the current bonobo controls per provider,
> but it will give us less work to do, since all this could be coded in
> the DB browser, or even, we can create a generic bonobo control which
> lets you do the same but for all providers.
> 

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.

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

> I think this is more flexible, and very useful not only in the Bonobo
> controls, but as part of the API.
> 

This way we try to win on both the simplicity of code and the performance.

Tell me what you think.

Cheers,

Vivien