Re: report engine

[Rodrigo Moya <rodrigo linuxave net>]

Hi all!

After a little chat on IRC with Derek and Carlos, I think I'd better sum
up my ideas about how I see the report engine. It is based on the
proposal by Derek, which I guess we all agree, don't we?

First, what I'm saying about including it in GDA does not mean that GDA
will have it included carved on stone, but that there will be a
separated, independent part of GDA, as the providers are. Right now, to
use GDA, you don't need to install all the providers. You install
libgda-x.x.xx (and libgda-devel... optionally), and then the provider
you need (gda-postgres, gda-mysql...), which can even be installed in
another machine.

Second, the report engine will need XML queries to be able to build
really-DB-independent reports. That is, GDA right now supports only SQL
(or whatever language the DBMS supports), but Vivien is working on the
XML query, which are an OPTIONAL way of sending commands to the
underlying DBMS. XML queries are a XML representation of a SQL command
(SELECT, UPDATE, CREATE ...), which is sent to the provider, which in
turn converts it to whatever it wants or it just processes it as XML.
Through the use of the gda_connection_supports function, clients can
know if the provider supports XML queries or not.

So, having the report engine in GDA will mean:
* add a gda-report application, which is a CORBA server implementing the
report engine's CORBA interfaces (to be defined). This is notably a GDA
client, that is, a program using the libgda-client for its database
access. As Derek says, we could code this so that later on a new way of
data access can be plugged in (this could be easily done with
GObject's). So libgda is just the default (and preferred) data access
middleware for the report server.
* add a libgda-report which is a wrapper for the client CORBA calls.
This will not depend on the libgda-client, since it's not a GDA client
(although it could), but a gda-report client. It will, maybe, depend
only in libgda-common, which is a library providing utility functions
for the rest of the GDA architecture (configuration and CORBA
abstraction, ...)

Using CORBA means that the report engine is itself a middleware, which
connects to GDA, which in turn is another middleware. So, now we're
really talking about N-tier architectures. Components of an applications
can be (each on one machine):

DBMS
      |
     GDA Providers (gda-postgres, ...)
         |
         GDA Clients                  Report engine (gda-report)
         |                                    |
         |------------------ Report clients (libgda-report)

This is IMO awesome. And the idea of the report server stuff Derek
talked about (cache, conversion to different formats, etc) makes me very
happy. As he said, and as I've suffered myself, there is no reporting
tools out there doing well the work (not that I know myself), so if we
do this right....

cheers