Re: Proposed changes in libgda

[Rodrigo Moya <rodrigo linuxave net>]

> 
> Am Sam, 04 Nov 2000 22:40:50 schrieb(en) Rodrigo Moya:
> > > * gda-init should be a part of the client library, because the server
> > > library has it's own gda-server-init, and it should have its own
> > > gda-init.h
> > > 
> > no, it will be needed for GDA-non-client applications, like the report
> > part.
> > 
> > > * gda-config should be a part of the client library, too, because it's
> > > purely client-sided
> > >
> > the same as with gda_init applies here.
> >  
> 
> Not sure if I explained that well. I understood that the gda-common
> library provides functions that will be used by the providers as well
> as by the "clients" of libgda (the code that is on the client side
> of gda.idl). The report engine is actually a libgda client.
> 
the report engine IS a libgda client, but the report client part IS NOT, since
it just communicates with the report engine, and it needs both CORBA/OAF
stuff (gda_init) and configuration stuff (gda-config). What could be
moved to libgda-client is the Gda_Provider and Gda_Dsn stuff, leaving then
the gda_config_ functions. If you think this is useful, just go on, I
don't care too much about this.

> > > * the names of the macros for the objects could be standardized (e.g.
> > there
> > > are now GDA_IS_XML_FILE, but IS_GDA_THREAD
> > >
> > yes, this is something I've been forgetting systematically. It would be
> > great
> > to provide a shell script which makes the change, so that client apps
> > just have to run it to conform with the new names.
> 
> It seems to me that more macros are missing than spelled wrong; and the
> only wrong-spelled macro names I found are in gda-xml-*, which is not
> used by client apps yet I suppose.
>
the only one I can think of is gda-xml-database.[ch] which is used by the
GnomeDbDesigner widget
 
> > > * Makefile.am's could be cleaned up a bit. GDA_CLIENT_CFLAGS/LIBS and
> > > GDA_PROVIDER_CFLAGS/LIBS should not be used for the library itself, but
> > > rather for the client apps and the providers. I say this because e.g.
> > > gda-server does not depend on libxml and GConf, and gda-client does not
> > > depend on libxml, GConf and oaf (of course this could change).
> > >
> > I'm not sure about this. Both the client and server libs use the
> > gda-common
> > lib, which in turn must link with libxml and GConf
> 
> a) for the CFLAGS part I can surely say that GConf is not needed for
> gda-client/server because that code does not #include gconf. CFLAGS is
> only the include path.
> b) for the LIBS part I can explain:
> If we have static libraries (.a), we don't need it, because static
> libs are _not_ linked. They are not more than an archive of one or more
> o files.
> If we have dynamic libraries, we can tell libtool what other libs my
> lib depends on, and when a program links to my lib, libtool makes it
> link to the dependency libs, too, automagically. This works with
> the ..._LIBADD automake parameter.
> But that would be enough to do for gda-common, because every program
> linking to gda-client will link to gda-common, too.
> I hope I explained understandable what I mean.
>
yes, now I understand. So, also ok with this one.
 
> > > * what would you think about a private header file in each directory
> > > (like common.h, defines.h or gda-clientP.h etc.) in which we include
> > > the things that are now included in all .c files (config.h, the NLS
> > > stuff...)? We would _not_ install that header, and it would be only
> > > included in our .c files, not in any other headers.
> > >
> > yes
> 
> So what name for this private global header file would you prefer? Is
> there any standard for this yet? (I didn't find anything)
>
no, there's not any standard, so just call it gda-xxx-private.h, for
instance
 
> > > * Gda_Recordsets defines signals, but they are never emitted. Maybe
> > > they could be removed.
> > >
> > yes, I'll have a look at it, because it is in its current state due to
> > the
> > fact that it's based on GtkAdjustement! instead of GtkObject. This should
> > also be changed.
> 
> You will find that I based the glib-version of Gda_Recordset on g_object
> and implemented the _move() function in another manner.
>
yes, the Gda_Recordset object needs a clean up. We'll have to look at it
to see how to make it more usable. And also to remove several IDL methods
which are not very useful and are not implemented.
 
> > apart from the comments, it looks perfect. So, please tell me on which
> > things
> > you want to work and I'll help you doing the other ones.
> 
> I'll work on the things you agreed upon and let you know if I have
> problems somewhere. It's actually a lot of little tasks, and I don't
> think I will interfere with somebody else; I will commit every part
> I've done as soon as it's finished.
> 
ok, great! Thanks a lot!

cheers