[gnome-db] Re: GRAND MASTER PLAN

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2004-03-08 at 01:43 +1300, Dru wrote:

> Ohh the flames.  I'm putting together this as a suggestion if we were to 
> work together. At the moment we arn't working together, and proberly 
> wont if we all continue down our seperate paths. There is a lot of work 
> we all still have to do on our own projects that, and working together 
> in the short run is going to be costly time wise. But in the long run 
> there are some large potential benfits. Gnome, mozilla, open office, 
> these were not built by individuals.  I think if we specalise a bit more 
> in our tasks instead of trying to do everything then it will make all of 
> our products better.  If we were going to work together, here are some 
> things i suggest.  Rodrigo and linas i want feedback.
> 
> Overall vision:
> 
> A complete database toolkit set that allow the easy rapid application 
> development of custom db appliations for gnome. Also a collection of 
> common business applications like accounting, payroll, inventory etc.
> 
I am myself just trying to get to the first thing, not to the common
business apps, but, of course, any work on the first helps the 2nd.

> This has to be comparable to commerical solutions that already exist.
> 
> Does this vision sound right?  If we are to find common ground then i 
> suggest we look at the supporting libraries and tools first.
> 
> 
yes, it does sound right, specially if we have each person concentrate
on the task he is an expert on. And that can only be done by sharing as
much technology as possible (of course, when and where it makes sense)

> Forms creation.
> 
> I think we all seem pretty confident in glade here. thats solved.
> 
> Database low level abstraction.
> 
> If we were to all use the same database abstraction layer then it will 
> make supporting a wide range of databases a lot easier. Also single 
> library to maintain and debug.  But everyone has their own code here.
> I've looked at both libdwi and libgda a lot but both still lack certain 
> minor features that are critical for my code base.  libgda has the low 
> level stuff but it also has support for all these other non-sql 
> databases and higher level stuff in there.  libdwi supports less 
> databases than libgda but is a pretty clean api.
> What if we ripped out the sql drivers,
>
which SQL drivers?

>  put a new clean api on it and 
> told libgda to talk to that api instead of directly as it is now. Modify 
> all our projects to talk to this new library/project?
>
I don't get what you're trying to say here, which API would be used from
libgda? which SQL drivers would be ripped?

> In regard to xml queries, a very useful feature but all my interfaces 
> are build around sql as is linas. I belive it would be more useful to 
> have a xml to sql and a sql to xml convertor or hide sql convertor away. 
> so sql'92 commands can be convereted into native sql commands.  And 
> proberly have that in the main libgda library.
> 
there is a fully implemented XML query management thing in libgda. It
supports most SQL commands, and allows that SQL<->XML conversion. The
only problem with it is that we haven't used it much, but it should work
straight on.

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

> Sql parser.
> 
> I find this is needed for a data abstraction layer. I'm not sure if you 
> have any sql langauge parsing done in your code linas or if you need 
> one, but bonddb and libgda are currently using the same code base here.
>
right, with some recent improvements from Vivien and yourself.

> I'd suggest moving libsql into a seperate library/package to make 
> maintaining it easier or moving it directly into a sql low level 
> abstraction library.  We should keep the sql parser to the sql standards 
> or aim for that.
> 
that sounds good to me, although it means more maintainance, but if
everybody needs it that way, then it's ok with me.

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

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.

>  Linas, maybe a gtk 
> output engine or a xml to gladexml converter, or use the existing html 
> output engine to allow you to embedded report into a gui before 
> preview/print?  Would you consider xml approach?
> Can gnome-db provide a highlevel reporting gui?
>
yes, that was the intention, to provide easily reusable widgets to
view / edit the reports.

>  One where you can run 
> reports, it asks for arguments for the reports and excutes the report? 
> Or where you can type an sql statement and it will put results into a 
> report.  Think mergeant reporting.
> Can gnumeric/abiword provide mail merge features from xml report?
> 
abiword already provides that, via libgda. Not sure how "mail merging"
could be integrated into Gnumeric.

> After a quick look here is the different reporting libraries i found.
> If you know of others that work well suggest them.
> http://rlib.sicompos.com/
> (havn't looked into in detail)
> http://papyrus.treshna.com/
> (lacks chart and editable content but is mature)
> 
> Report Designer.
> 
> None of have anything here (expect gnue).  Its needed. I was thinking 
> orginally using openoffice or abiword to design reports but i really 
> havn't started looking at this at any detail. Any suggestions on how we 
> are going to achive this? Does this sound feasible?
> 
using abiword for reports seem, as Martin said, feasible, so I'd say
yes.

> The Widgets.
> 
> We all agree on gtk here. But gnomedb has its modified widgets. I think 
> this will remain seperate in the general widgets (like GtkEntry, etc)
> because its so dependent on the data abstraction layer.  If non-standard 
> widgets in our projects allow populating by alternative data abstraction 
> layers it could help a lot, i'd like to use a dbgrid style data entry 
> form for payroll time sheets.  Maybe i should write a bonddb -> 
> GdaDataModel convertor.
> 
the data model-based architecture makes it easy to make the gnome-db
widgets aware of any external data you might need. You are right though
in that it would be pretty nice to have normal GTK widgets use the
libgda structures.

> The middlebits.
> 
> I have no name for this but this is the bit dwi and bond do.  Populate 
> and make applications work at runtime. We can deal with this later.
> 
> Reasons why:
> http://linas.org/theory/application-devel.html
> 
> Links:
> Lina's approach:
> http://dwi.sourceforge.net/
> My approach:
> http://bond.treshna.com/
> 
> Database Administration/creation.
> 
> This should be handled by mergeant.
> 
right, if we all use the same base technology, each app can perfectly
concentrate on its specific features, so mergeant would be the DB admin
tool, GNUCash will provide the accounting/financial libraries/
components, bonddb/qof will provide the RAD thing, etc

Also, as some people have mentioned, it would make it really easier to
have all that data available to Gnumeric, Abiword, etc, for reporting,
mail merging, etc, etc

> Finincial Objects.
> 
> In my initial work for a payroll system i designed a finical system, I'm 
> assuming you already have one linas. Maybe we should aim to have some 
> design rules for our db schemes so it would be easily to intergrate 
> payroll and accounting transactions?
> 
> The Politics.
> 
> Do we all fall under gnomes ?
>
I am, although, of course, I've got nothing against making all of these
cross-platform.

cheers