Re: [Tracker] Mining GVfs metadata

[Ivan Frade <ivan frade gmail com>]

Hi,

On Fri, Nov 19, 2010 at 6:28 PM, Tomas Bzatek <tbzatek redhat com> wrote:

Hello Tracker developers,

for gnome-shell experience (and later Nautilus usage) we would like to
use Tracker for indexing various information from gvfs metadata.

Great to hear that!

Typical example is storing icon positions and emblems in Nautilus or
last played position in Totem for playback resume. Analogy to cookies.
Metadata disappear when file is deleted.

UI information shouldn't be in tracker; but "emblems" can be considered tags and the "last played position" is a good property for a media file (you could continue playing with a different media player!).

Is there a predefined list of "metadata::" keys? or is completely free text? The first case would make our life much easier.

I've been talking to Alexander Larsson, creator of gvfs and
gvfs-metadata and we came with the following proposal. When a write
event occurs, gvfsd-metadata will notify Tracker daemon via dbus message
that something has changed. Tracker service will then schedule update of
gvfs metadata trees, using custom module. Only changed keys (since last
update) would be extracted. On first use, Tracker will use that module
to extract all available metadata.

gvfsd-metadata notifying tracker of changes is definitely the way to go. Could that daemon provide directly the data? it can save tracker the work of reread the attributes and calculate the difference.

Now I'm not familiar with Tracker architecture much but having
possibility for pluggable miners would be great.

"Miner" is just "something that push data into tracker-store". They are completely independent from the store and can be developed out of the tree. The idea is that each distribution (or even user) chooses its own combination of miners, some provided by tracker (like filesystem), some written by other teams.
 

The code should live in
gvfs tree since it would use internal structures and functions. So we
would maintain our Tracker plugin, reflecting changes in Tracker API
etc. The thing is that GIO by nature doesn't have functions to work with
gvfs metadata database, it is something internal to gvfs that we want to
exploit this way.

In an ideal case, gvfsd-metadata itself would be a "miner", translating metadata writing events into tracker metadata. If this is not possible, then the miner-fs must read the extended attributes (shouldn't have a big impact in the code). I wonder how this is combined with inotify.

I am not familiar with GVFS details but the idea sounds really great and we are happy to help. We are also around in IRC (#tracker in GIMPnet).

Regards,

Ivan