Re: New Anjuta dependency: libgda-4.0
- From: "Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>
- To: "Luca Ferretti" <elle uca libero it>
- Cc: Vincent Untz <vuntz gnome org>, desktop-devel-list gnome org
- Subject: Re: New Anjuta dependency: libgda-4.0
- Date: Fri, 11 Apr 2008 10:01:18 +0200
On 10/04/2008, Luca Ferretti
<elle uca libero it
Il giorno mer, 09/04/2008 alle 12.05 +0200, Vincent Untz ha scritto:
> Le mercredi 09 avril 2008, à 00:19 +0200, Johannes Schmid a écrit :
> > For now, this is just an optional dependency but when it is more stable,
> > it's likely that we will remove the old symbol-browser and make the new
> > plugin the default. However, we either need libgda-4.0 as external
> > dependency or as Desktop module for GNOME 2.24.
> Just to clarify: are you asking that we add libgda to the list of
> blessed external dependencies or somewhere in the GNOME release suites?
IMHO the issue hare is more generic: currently the GNOME
Desktop/Platform lacks an official "dependence" to store data in a
database structure and a library to access to those data using
To develop a rich and full featured application, ISV and ISD could need
to store data in more complex and performing structure than XML (libxml
and lib) or INI (glib). Anjuta is the fist application officially asking
for it, but we yet have F-Spot that stores the photos metadata using the
database interfaces available in mono.
If we really want to provide something like the Core Data from Apple
or QtSql from Trolltech I think the blue sky scenario is:
1. add a sql database engine/library as external blessed dependence
- SQLite seems the de-facto standard for "desktop computer
applications" (note we are choosing a database to store your
music library or the previously mentioned photos metadata, we
don't need MySQL, PostreSQL or Oracle, so don't flame about
"$DATABASE is better")
2. add a Glib/GObject oriented wrapper library, not in "Platform
Libs" but in "Desktop Libs"
3. lobby core applications to use the official database and/or the
official wrapper library
This seems the most rational approach to me, while I still have some
* is libgda "well behaving" for this purpose? I'm not saying
libgda is bad and I don't have the knowledge to technically
review it, but I know that it has a long list of supported
database providers: it's more a meta-wrapper then a wrapper.
Isn't a little oversized as "Desktop Lib"?
* evolution-data-server: can we port it to use SQLite or libgda
instead internal libdb? should it use its private database or
it's better store email indexes only in the
$YOUR_PREFERITE_SEARCH_ENGINE index and query using Xesam? Of
course waiting Xesam 1.0.
* same question for other apps like f-spot (photo metadata,
rating, user comments and tags), rhythmbox (song metadata,
rating), epiphany (history and bookmarks) and other applications
that are using sqlite (like f-spot) or could like to use it
(like rhythmbox or epiphany): is a good idea use a private
database for data that you could need to search "from the
I think there are two use cases (which are quire different) that you try to address.
* Applications with private needs for a database with many of the features modern databases provide - I think libgda is the best option here. Fx. Anjuta's symbol db, stock keeping apps, etc.
* Apps with need to store metadata that could find usage across the desktop (Rhythmbox, F-Spot, etc). Xesam will soon provide a dbus interface for this and I will implement a client for this in xesam-glib when the spec is ready. It should be noted that Xesam 1.0 will only provide a dbus interface for searching in a shared index (Beagle, Tracker, Strigi), not an interface for storing data - that will come post 1.0.
Ideally I would like two libs to address each use case in the desktop module (fx libgda and xesam-glib). As you also point out the first use case more or less requires that sqlite be a blessed dependency.
] [Thread Prev