[gnome-db] Re: GRAND MASTER PLAN
- From: Dru <andru treshna com>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Linas Vepstas <linas linas org>, msevior physics unimelb edu au, gnome-db-list gnome org, Charles Goodwin <charlie xwt org>
- Subject: [gnome-db] Re: GRAND MASTER PLAN
- Date: Sat, 13 Mar 2004 14:46:37 +1300
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
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
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.
Should papyrus be add as a seperate compoonent to the
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?
] [Thread Prev