Re: Proposed module: tracker

[Jamie McCracken <jamiemcc blueyonder co uk>]

Joe Shaw wrote:
> 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:

all these also apply to EDS too yet no one complains?

A central store has been successfully used in BeOs and Vista also has 
similiar.

Tracker is object to object with key values as properties so it can do 
more complex stuff (like a playlist object is a collection of music 
files). It now has metadata relationships so much smarter searches are 
available.

If we ever want first class objects or semantic web style functionality 
then stores like tracker/EDS are needed.

They are not slower - in many cases they result in far fewer disk seeks. 
The key is to get stuff in bulk (like get all the properties in one call 
 as opposed to getting each individual ones separately). This 
eliminates the IPC overhead (something GConf needs too)

We are planning to back up all metadata in either exattrs or an XMP 
format. This also helps with moving data off machine and preserving 
metadata.

And one API is easier to learn than a multitude for different metadata 
and keyword systems (honestly how many systems do we need to do tagging 
and metadata?).

And no it should not be more cumbersome than existing methods + you get 
the benefit of powerful search on the metadata (and I dont mean just the 
limited searches of indexers but the database sql ones that do substring 
wildcards and RegExp too)

Some examples of how tracker can improve the desktop :

Lets take the .desktop files that make the menu slow - tracker can cache 
these in its database, use inotify to keep them up to date  and spit 
them out considerably faster than manually parsing each .desktop file.

Another example is if rhythmbox used tracker as its database then its 
pretty much guaranteed to have an up to date listing of all music files 
with no need to watch or scan directories for files. Another music app 
could also connect to it and get the same benefit with much less code.
(the same can apply for GThumb/Fspot with photos)

Tracker can create a faster and more powerful desktop but yeah to prove 
that I would probably have to write Topaz :)


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/