Re: New Anjuta dependency: libgda-4.0

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

On 10/04/2008, Luca Ferretti <elle uca libero it> wrote:

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
Glib/GObject approach.

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[1]
or QtSql from Trolltech[2] 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
doubts:
      * 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"?[3]
      * 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
        outside"?

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.

Cheers,
Mikkel