Hi, On Fri, Nov 19, 2010 at 6:28 PM, Tomas Bzatek <tbza...@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
_______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
