[gnome-db] GRAND MASTER PLAN



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.

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.


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

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?

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

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

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?

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

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 ? We have to at some point stop focusing on these low level tools and start making some real applications. And know where to share code where we can. Maybe have a common organisational group we can all belong to with links to our sites with, like gnome office and list what we each work on? so we know what each other is up to and have a common banner to achieve our vison. I would in a way like one day to have a website we we list a whole lot of database applications for gnome.


.


Even if we dont merge at any level we should still at least be aware of what each other doing so we can steal ideas of each other. True compitition only exists with perfect communication. We are to busy developing our own applications to both seeing what each other is up to and their features. And we should concentrate on doing what we each do best.






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