Roadmap to 0.7
While I was at the desktop summit, I decided to come up with a roadmap so we all had something to work to for the 0.7 unstable release which we are hoping to do soon. The roadmap is on live.gnome.org here:
http://live.gnome.org/Tracker/Roadmap
As you can see, it is progressing nicely.
Config
The configuration system in Tracker has always consisted of one TrackerConfig inheriting from a GObject and used to load/save applying the GKeyFile API. The problem we found here, is that we really want configurations to be more fine grained to specific binaries. Some of the options (like log verbosity) would apply to ALL binaries that use the config otherwise. So now we have TrackerConfigFile as a base class with tracker-object-keyfile.[ch] to do some utility functions for us in libtracker-common and all binaries that want their own TrackerConfig with object properties now inheirt from TrackerConfigFile. This is quite nice because it reduces the code duplication we had and now we have a nice set of separate config files in $HOME/.config/tracker/.
With 0.6. we also had this concept of “modules” which would be for each type of data we wanted to track. We had “files”, “applications”, “email”, and some others… These modules also have a configuration pertaining to how to index their data. Things like globs for including and ignoring certain files. There are also options to make sure data isn’t indexed too regularly (which was needed for some content that was constantly updating). All of this is in the process of being revised and merged with the TrackerConfig machinery. This mostly applies to the “files” module though. The module config and module code (which was a complex GModule implementation) is all going to be simplified now that we have separate binaries for mining each data we are interested in.
Album Art
This was quite a mess before. We had code in different places for this. Over the past week or so I have cleaned this up too. Now we do all album art downloads and extraction from the tracker-extract binary (called from mp3 and gstreamer extractors when they see media with such content). Before we would request thumbnails for the new art in tracker-extract, but due to the unstable nature of tracker-extract (based on dynamically loading modules using 3rd party APIs we can’t guarantee the stability of) we were always at risk of failing to queue new thumbnail requests to the thumbnail daemon if we had a crash. We only send thumbnail requests AFTER all indexing has been completed, if we don’t do this, we suffer with severe performance problems. Now all thumbnail requests are done from one place, the tracker-miner-fs and the albumart functions are no longer spread across libtracker-common and tracker-extract. They are just in tracker-extract.
Volume Support
Over the past few days Carlos re-added volume support to Tracker so now using a simple query, you can find out if your data on that MMC you just inserted or removed is available.
So, to get a list of ALL data objects and their availability (which is true or false based on if the media is mounted or not) you can use:
$ tracker-sparql -q "SELECT ?do ?av WHERE {
?do a nie:DataObject ;
tracker:available ?av }"
You can also get a list of all data objects which are NOT available. To make things faster, we have not included “available” for EVERY item, only where items are available. This makes updating the tables a lot faster. So when looking for files which are not mounted, the query becomes a bit more complex:
$ tracker-sparql -q "SELECT ?do WHERE {
?do a nie:DataObject .
OPTIONAL {
?do tracker:available ?av } .
FILTER (! BOUND(?av)) }"
Of course the most common use case is, tell me files which are available, which can be done with:
$ tracker-sparql -q "SELECT ?do WHERE {
?do a nie:DataObject ;
tracker:available true }"
We are still fine tuning the volume work to be faster but things are coming along swimmingly!