[Tracker] Mining GVfs metadata

[Tomas Bzatek <tbzatek redhat com>]

Hello Tracker developers,

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

Basically, when we say "gvfs metadata", it means setting values in
"metadata::" namespace using GIO. Metadata are bound to a particular
URI, a file/directory on local disk or VFS. Metadata in our definition
are small pieces of information that are not guaranteed to be
persistent, i.e. applications should not rely on stored information.
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.

Gnome-shell (and Nautilus later) would benefit from having possibility
to quickly find files with certain gvfs metadata, simply by combined
SPARQL query. One example is tagging and categorizing files. Rather than
having some kind of internal database, it is better to use gvfs
metadata, which would retain metadata on file copy or move operations
automatically.

Physically gvfs metadata are stored in separate databases in
~/.local/share/gvfs-metadata. We don't use xattrs. A dedicated daemon
gvfsd-metadata is coordinating writes.

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.

Now I'm not familiar with Tracker architecture much but having
possibility for pluggable miners would be great. 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.

I'm open to any comments, please discuss.

Thanks,
-- 
Tomas Bzatek <tbzatek redhat com>