On 10/04/2008, Luca Ferretti <[EMAIL PROTECTED]> 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
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
