GRAND MASTER PLAN

[Dru <andru treshna com>]

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.