'data-aquire' service and libgda

[Rodrigo Moya <rodrigo gnome-db org>]

Hi

As was said in the IRC meeting, we have to define interfaces for
different things in libgnomeoffice. One of these interfaces I've thought
about is a 'data-aquisition' service, to get data from a GO app into
another GO app.

This service would just contain a set of methods for sending a request
for data ('a query') and get back an array of data (rows/columns), as in
a database SELECT.

For this, we need to use data types that are easily understood by *all*
GO apps. And, here comes libgda into the picture.

As the big drawback for people to use libgda have been its CORBA
dependencies, we've decided to remove those dependencies, and replace it
with a simple GModule-based plugin system, thus leaving the set of
dependencies to glib/libxml2.

This work has already been done (thanks to the clean hidding of the
CORBA layer work we did for the GNOME 2 port), and is only missing a
couple hours of my time to make it work.

So, I am proposing to use libgda for the base of this 'data-aquisition'
service for many reasons:

* glib/libxml2 only dependency (also libxslt, but that can be optional).
This will make it compilable in other platforms, such as windows/mac,
etc, which seems to be important for some GO apps like abiword.
* a model-based data-aquisition framework (GdaDataModel), and a nice way
to pass values between unrelated apps/libs/whatever (GdaValue)
* GdaDataModel and GdaValue are totally database-independent, they don't
need a database to work, they are just an abstraction of an array-like
set of data (rows/columns)
* using libgda will allow us to offer standard services in
libgnomeoffice, so that we can just add one 'aquire-data-from-database'
service to that library and have DB access-with-no-extra-dependencies to
ALL GO apps, which seems like a nice thing to have, at least for
Gnumeric and Abiword, and I guess also for MrProject.
* also, access out-of-the-box-with-no-dependencies to many DBMS
supported already in libgda (PostgreSQL, MySQL, Oracle, ODBC, SQLite,
Interbase, Sybase). The support for those DBMS is distributed in
separated packages in the form of GModule-based plugins.

All this means that we can have a service in libgnomeoffice called
'get_data', for instance, and do, in any GO app:

GdaDataModel *model = go_service_get_data ("SELECT * FROM whatever");
for (r = 0; r < gda_data_model_get_n_rows (model); r++) {
	for (c = 0; c < gda_data_model_get_n_columns (model); c++) {
		GdaValue *value;
		char *contents;

		value = gda_data_model_get_value_at (model, c, r);
		contents = gda_value_stringify (value);
	}
}

as you see, with these lines of code, you are able to get data from a
database, and (again :-) with no extra dependencies. Also, this can be
used for non-database stuff as well, which is why I'm proposing to add
libgda as a dependency for libgnomeoffice. For instance, implementing
this 'get_data' service in other non-database GO apps (MrProject,
Evolution, Gnumeric) would be as easy as creating a GdaDataModel, which
is easily done with libgda API, which contains many different types of
data models (GdaDataModelList, GdaDataModelArray, etc).

I think this can serve as a good way of sharing structured data
(rows/columns) between all GO apps.

so, thoughts?

cheers