[gnome-db] Re: GRAND MASTER PLAN

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

bonddb use a bonddbwrapper library which uses postgrsql. I can replace the bonddbwrapper library with libgda.


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.


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.

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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]