[gnome-db] Re: Dynamic data queries
- From: Dru <andru treshna com>
- To: Linas Vepstas <linas linas org>
- Cc: Andrew Hill <dru treshna com>, Charles Goodwin <charlie xwt org>, gnome-db-list gnome org, gnome-office-list gnome org, gnucash-devel gnucash org, Tim Lord <timl treshna com>
- Subject: [gnome-db] Re: Dynamic data queries
- Date: Fri, 05 Mar 2004 15:04:15 +1300
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]