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 <tbza...@redhat.com> _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list