[gnome-db] Re: Dynamic data queries



Linas Vepstas wrote:
On Fri, Mar 05, 2004 at 04:44:37AM +1300, Andrew Hill was heard to remark:

Charles Goodwin wrote:


On Tue, 2004-03-02 at 16:18, Linas Vepstas wrote:



Well, yes, OK, its not SQL that's broken; its that there are no
client-side sql parsing tools that can be used to map sql
statements onto C objects (or java classes or python objects....)
But you got the point!

Not true: There's www.hibernate.org for Java and I know there's one for
Python too.  I concede that I've not heard of one for C.



http://bonddb.treshna.com for client side sql parsing and mapping sql statements to c objects
and libsql in libgda for client side sql parsing, both written in C.


Funny about how everyone tries to invent the same technology at
the same time.  Of course, it's frustrating to be the author of
something like this, creating it because no one else has done it,
and then when one finishes, one finds out there's some other guy
out there who did the same thing, and they claim they've done it better than you! (That is, at least, part of the tension that I feel).

The greatness of compititon. I really enjoy having more than one open source projects in fields. though in this case of database application development for gnome we have so many different projects (and thats ignoring the kde market) that it does seem a bit silly with the limited user base, even though its useful for me and linas to steal ideas from each other. And with all these solutions theres no really good solution that can be a good alternative replacement for borland/ms access/vb etc. Of course this is all clouded by the html approach and everyone predicting that web based database applications will be the future mainstayer in this field. A lot of solutions are out there for straight db adminstration and table modification but this not the same as having a database frontend.

Heres the gnome projects and some negitive comments

gnomedb - gnome's approach, a nice db wrapper and widget wrapper. Though lacking in the bits in the middle. You can code large db apps with it but it involves repetitive work. gnue - fsf attempt, personally think development cycle to slow and too community focused. suffers from lack of coders that want to get hands dirty. Isn't very flexiable.
dwi - linas & gnu cash approach, project still needs a bit of work.
bond - my approach, still has lots of bugs and it cant support the extent of user interface designs that i want it to. needs more than just postgresql support and its a very small team and community. openoffice.org - ms office copy cat approach. I dont see open office team been able to easily create a ms access replacement and i'd prefer them to improve other parts of openoffice.

I think a lot of the problems is we are all trying to achive the same things and developing all the same tools, the complete tools. While the fundementals can be different there are a lot of support areas that can be the same. Ie. dwi, bond and gnomedb use glade as a common forms designer while openoffice and gnue have developed there own approach. For reports everyone is working on there own packages. For database backends wrappers we all have differnent approachs again. bond and gnue orginally had the same database backend code many years ago but that didn't last long. libgda is fundementially different to bonddb & dwi though bonddb and dwi are very similar. libgda is a db wrapper, while bonddb & dwi sits on top of the sql client end. bonddb and libgda share the same sql code base which is good, maybe sharing same reporting engine will also help all the projects along.

glib and gtk is very nice, though i still use my own memory management, logging and config file reading tools. And i wrote a dynamic simplistic run time loader of gtk to be less gtk dependent and allow easier porting.

Back to the applications. The reason we all doing this is we need database applications. Ie accounting, payroll, inventory etc. I can only write so much. as can we all. I'm personally working on mainting a gnome payroll system and a membership database with bond, and i use gnucash for accounting purposes. We do need to share code when appropriate and not when its not. And not all try and create every component. Maybe libsql in gnomedb should be a seperate library/project which both our updates go into?





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