Re: Proposed module: tracker

[Joe Shaw <joeshaw novell com>]

Hi,

On Mon, 2007-01-08 at 20:47 +0100, Steve Fr�naux wrote:
> Jamie McCracken wrote:
> 
> > in any event tracker can be configured to not index at all or only index 
> > metadata and/or contents. It can also be used a stand alone metadata DB 
> > so I think tracker should be flexible enough for most cases where you 
> > only want a subset of its features.
> 
> In that case, could it be used as a metadata storage for application 
> data concerning files ? Such applications are nautilus or gedit or evince...
> 
> Also, didn't rhythmbox have a project to use tracker as its music 
> database ? What's the status of it ?

I'm not sure I understand this world view.  People in this thread have
been saying things like, "We need a metadata solution."  But I haven't
seen anyone yet articulate what the "metadata problem" is, or how
Tracker specifically is supposed to solve it.

I know that Jamie recently said that he's only proposing the Tracker
indexer and search tool for inclusion, but as long as Tracker includes
the metadata stuff, it's just as much a part of the desktop as the other
stuff, unless it's shipped separately.

Using Tracker as a general store feels makes me feel very uncomfortable.
Most of these are not necessary cons against Tracker per se, but apply
more generally to idea of a centralized, generic data store:

        * It lacks the simplicity of already existing APIs for storing
        data, like GKeyFile.
        
        * It lacks the portability of something like XML.  If you want
        to get that data out, you have to export it somehow.
        
        * Availability becomes a problem that the application developer
        has to solve.  What happens if the Tracker service isn't
        running?  Is the data simply lost, is there a fallback, is an
        error displayed?  
        
        * Speed is a real concern on large datasets, because each time
        you touch the store it's an IPC.  We've seen similar problems
        with GConf over the years.
        
        * It lacks the specialization of a database setup like sqlite.
        Tracker is essentially key-value storage, which isn't well
        suited for a large number of tasks, IMO.
        
        * There is potentially a single point of failure.  In a naive
        implementation, if the store is corrupted, all of your metadata
        is simply gone.

Assuming 1:1 feature parity between a non-Tracker implementation and a
Tracker one, my belief is that the Tracker implementation will require
more code and introduce more complexity into the application side.

It seems like the right approach here from a desktop-wide standpoint is
to stop siloing data inside our applications and make them generally
available to the desktop at large, keeping in mind that "change
notification" is probably the most important aspect to outside
applications.  This can be done either through making the data files
accessible themselves and considering them part of the ABI, or by
creating programmatic interfaces to them (either libraries or via
D-Bus).  Outside applications can then consume that data as they see fit
-- including indexing services -- while managing their own metadata, or
using specialized desktop services (like Leaftag) for this purpose.

Joe