Re: Dynamic data queries

[Dru <andru treshna com>]

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?