libgda .... Re: GnuCash page on GO site

[Rodrigo Moya]

On Sat, 2004-03-06 at 11:07 -0600, Linas Vepstas wrote:

> On Fri, Mar 05, 2004 at 05:27:32PM +0100, Rodrigo Moya was heard to remark:
> > so, your database is a XML file then?
> 
> gnucash supports the storage of data in both xml and sql. 
> 
and what API does it use for the sql case?

> > libdbi does what libgda does, so there's no point in using one from the
> > other.
> 
> OK, then I misunderstand libgda. 
> 
right, indeed, if your opinions were based on the 3-or-more-years-old
0.2.96, I guess you don't know libgda at all. Current libgda (1.0.x) is
totally different from the GNOME 1.4-based one.

> libpg and ODBC and libdbi are low-level communications 
> libraries that do not offer any sort of abstraction, they're 
> just straight-ahead API's for SQL database acess.  They are 
> adequate for what they do.
> 
right, libgda is that, and a bit more. We are trying to make libgda a
"perfect" data access and management, so the goal is not just to be a
low-level abstraction, but a high-level one, accompanied with utilities
classes and functions to easily manage the data.

> But I thought the goal of libgda was to provide a set of high-level
> abstractions to multiple data sources, including sql and xml and ldap,
> which would imply that libgda is comparable to other high-level
> abstraction libraries.  But maybe that is libmergeant.
> 
libgda provides, again, a level of abstraction over different RDBMS
(including non-databases, like XML files, ldap servers, etc). libgnomedb
is a set of simple widgets to display and manage DB data accessed via
libgda. libmergeant provides a data dictionary, using both libgda and
libgnomedb, which makes it really easy to develop apps that manage the
data in different data sources, with extra things like cache, updatable
widgets (that send the modifications made by the user automatically to
the underlying DB) and other goodies.
Development of libmergeant is now separate, but it will probably be
integrated into libgda (non-UI parts) and libgnomedb (widgets) as soon
as it's ready.

> Finding the correct high-level abstraction is difficult, which
> is why I kept harping on bond and gnue and qof and dwi.  
> None of those packages do it all, they're all shit, they've
> all got major faults and shortcomings, but they're all 
> that we have today .
>
right, so we probably should come up with a solution that fits
everyone's needs? Thats the intention of gnome-db, longer term, but we
add features a step at a time, because we want to have solutions
implemented and designed by the people who need them, instead of doing
yet-another-custom-made solution that only fits our needs.

That's why I've been asking about how to better integrate everything.
Some progress, as I already said, was done with bonddb and papyruys,
although still needs a lot of work.

>   It would be very nice to have a 
> database abstraction layer that combined the best features 
> and aspects from bond and gnue and qof and dwi (and mergeant 
> too I guess). I was hoping to have a conversation about 
> the high-level database abstraction layer.
> 
this conversation was about that. libgda provides that abstraction layer
(with all its shortcomings, of course, which is why we need to know what
you need from it, so that we can add it), so it makes sense to at least
start sharing technology for that. Of course, IMHO.

cheers