[gnome-db] Re: GRAND MASTER PLAN

[Dru <andru treshna com>]

> that's a bit of a hell for maintainance, and for development, since you
> need to know which parts you are using, which adds complication.
>
> > My code could link to the libgda_dbabs and libgda_providers initially. 
> > Reports would properly link to all of libgda.
>
> the report engine in libgda is in its own library. The XML queries stuff
> could also be in a separate library, but the rest, it does not make
> sense to me to split it into o many pieces.

I suppose its more differences in design approach when it comes to c 
libraries. what i find is easier you find harder.  I just like taking a 
hacksaw to everything and cutting into lots of little bits.

> > > > Data abstraction layer.
> > > >
> > > > This layer that deals with dynamic data sets. Doing the write backs and 
> > > > saves of data.  There is libgda, bonddb, gnueappserver, qof. Dont touch 
> > > > gnueappserver, i wrote it and it suxs. I dont think we can look at 
> > > > working together on this one until we sort out the low level abstraction 
> > > > db.  How far are you down the track for qof linas?
> > >
> > > bonddb uses native PostgreSQL libraries for psql access, IIRC. QOF, IIRC
> > > what Linas said, uses a XML backend. So, and sorry for saying it myself,
> > > the choice here seems to be libgda. I am talking just about the low
> > > level data access stuff, not about the extra features bonddb and qof
> > > provide.
> >
> > bonddb use a bonddbwrapper library which uses postgrsql. I can replace 
> > the bonddbwrapper library with libgda.
>
> right
>
>
> > Data abstraction layer i'm talking about is the bonddb DbObject, linas 
> > qof stuff, and the GdaDataModel in libgda. Libgda aims to provide the 
> > same functionality as bonddb so it makes it harder to intergrate unless 
> > we refine the apis more.  Low level stuff should be in libgda yes. but 
> > managing datasets is each has its own way of doing at the moment.
>
> hmm, what sense would libgda have if it just allowed to connect to
> databases and not deal at all with the datasets?

I see that there are two different data sets, low level data sets and 
high level datasets. Ie a PQresult and a GdaDataModel

> I dont think, contrary to what Linas thinks, that libgda provides all
> you need, but for the data access part, it provides all you need, IMHO.
> bonddb has, on top of that (provided by libgda) a lot more features, so
> I don't see the competition at all.

I should just impliment it and see how it goes.  A part of me is tempted 
with libdbi
for its pure simiplicity.

> > > > Reporting
> > > >
> > > > I think we definetly need a common ground here or not write our own.
> > > > Unforuntly i already wrote my own, papyrus (stealing ideas from gnomedb) 
> > > > when there was nothing providing reporting, now there are dozens of 
> > > > reporting solutions out there (half are java/html though).  Linas, i 
> > > > know how reports are done in gnucash and they are dynamic. A reporting 
> > > > system should generate pdfs,ps,xml,html etc. And use the database low 
> > > > level abstraction library. Can gnomedb people use papyrus or another 
> > > > reporting engine, what is gnomedbs requirements?
> > >
> > > gnome-db can use papyrus, yes, although for that, it would need to use
> > > libgda, to make things easier to use / integrate.
> >
> > I can switch papyrus other to libgda pretty easily. Only take a few hours.
>
> great, would that make sense to you, after all these conversations?

I'll start on it today and see how far i get.
http://bugzilla.treshna.com/cgi-bin/bugzilla/show_bug.cgi?id=157

> > > gnome-db's requirements are not clear, we wanted to provide a "powerful,
> > > generic reporting system", with the low level stuff in libgda (look at
> > > libgda/report for the code written so far) and a report viewer / editor
> > > widget in libgnomedb.
> >
> > What sort of low level stuff in libgda? 
>
> opening databases, getting and modifying recordsets, tranactions, etc,
> ie, the basic stuff you need when dealing with data sources

All it does is parse strings to the underlying backend. So in effect it 
would
be just parsing query strings to libgda. Recordsets navigation is done 
by the reporting engine as it populates the report.

> >  I havn't touched or done any 
> > report viewer or designer. I used gnome pdf viewer for my report viewer.
>
> well, that might be an easier solution to the problem. We can just
> generate the PDF from a GUI and use the PDF Bonobo component to display
> the generated PDF.

Its simple.

> > Should papyrus be add as a seperate compoonent to the 
> > libgda/meargent/gnomedb set?
>
> if you want to, yes. The original idea in libgda was to provide, along
> with the reporting feature, an API for apps to eaily manage reports
> themselves. Could papyrus provide that? If so, I guess it could be into
> libgda, but as a separated package, if needed.

Papyrus can't provide any interfaces for managing reports themselves. At 
the moment i'm doing all that within bond. So it would be dependent on 
something else for managing the reports.

Should papyrus be in gnome-cvs? and we use tools to sync it? Does anyone 
in gnome-db have any immedidate needs for reporting to test it? How are 
we going to proceed on the websites of gnome-db and papyrus? Whos 
working on the gnome-db reporting stuff at moment?