Re: report engine

["Derek A. Neighbors" <derek gnue org>]

Been away from computer for several days.  Just reviewing some old mails
and replying to this one to see if I remember things properly.

> 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?

As far as I know we are sticking to the basic principles of the idea. :)

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

I think we came to conclusion it would be more like a client than a
provider thus possible argument for not being a GDA component.

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

I think we agreed just like a normal client it should be able to do
either SQL or XML Queries.  Since XML Queries are not done or polished I
would suggest using normal SQL for now to get things up and running.  As
"True" independence is not absolute highest priority in this stage as we
are just trying to get the tools working. :)  Not making massive
applications with them. (Yet!)

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

Rather than "add" I would say create. :)

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

I think I agree with this, though need clear mind to decide in whole.  
 
> 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):

Yep.  That was the idea all along.  In the case of GNUe we plan on
client->reportServer->bizTier->dataTier. :)  I need to fix my diagram as
it has GEDI/LibGDA in one block when they should be separated as TWO
blocks to show 4 tiers instead of three.

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

If we do this right, I will have a lot less headache at work. :)

Derek Neighbors
GNU Enterprise
http://www.gnue.org
derek gnue org