Skip to content

Add tracker3 module

Carlos Garnacho requested to merge wip/carlosg/tracker3 into master

Given the API and structural changes in Tracker 3.x, it makes sense to develop support for it as a separate module. This MR copies the Tracker 2.x module with minimal changes so it builds, and reworks its internals so it becomes a good Tracker 3.x citizen using more modern query language features and cached statements.

There's multiple relevant changes in Tracker that affects the features covered by the grilo plugin:

  • The SPARQL service being queried is now explicit
  • Tracker-miner-fs separates in different graphs
  • File and content data are now logically split.
  • Tracker-miner-fs data is no longer considered world writable
  • Writing data back to files no longer happens implicitly, it requires a explicit call to the Tracker writeback service

The first 2 involve changes in how the queries are performed, so they query tracker-miner-fs specifically, and are more effective in fetching data from the specific graphs without overly generic queries. The 3rd involves some changes in how some properties are fetched to stick with content data and avoid file data. These changes are all internal and shouldn't reflect in any way on the outside.

But the last 2 bring some visible changes in the GRL_METADATA_KEY_* that are supported and meaningful. Tracker-miner-fs data being readonly means that it can only be populated with metadata from indexed files, other "logical" content that was deemed world writable (like GRL_METADATA_KEY_FAVORITE or GRL_METADATA_KEY_LAST_PLAYED) no longer is. There is the same problem with storing that metadata, as it does not map to tags we can store in files.

With Tracker 3.x, the official way to extend the data is to have your own local database (having it share the Nepomuk schema is not mandatory). The Grilo plugin has the minimal ground work to cooperate with clients wanting that, it has a configuration option so it can get a private database path and perform queries through such private connection (even though the queries access the tracker-miner-fs service). This should be just enough to allow registering your own metadata keys and bring that data up in grl_source_query() query strings. E.g.:

my_fav_key = grl_registry_register_metadata_key (registry,
                                                 g_param_spec_boolean ("myfavorite", ...), ...);
...

grl_source_query (source, "?url foo:isFavorite ?myfavorite", g_list_prepend (NULL, my_fav_key), ...);

But unfortunately storing metadata cannot be mapped the same in a generic manner. For the most part this is irrelevant to most grilo users, except maybe GNOME Music. I see several options here:

  • Consider this enough. Clients already require knowledge about their own database, so they may as well perform SPARQL updates to it.
  • Beef up the Tracker writeback service, make it sure metadata is always written back, eg. using XMP sidecar files as a last resort. This also makes supporting multiple databases in Grilo code more moot.
  • Go crazy in the Grilo plugin and support a private store out of the box, merge local and "remote" miner-fs data where necessary, and have it store those "logical" metadata keys in the local store. This makes it easy for GNOME Music, but this (un)mapping of "local" vs "remote" metadata keys seems a complication.

Besides that, there's some other improvements in this MR, store_metadata() support doesn't cover for those logical tags, but it extends the support to be maybe worthwhile for a tag editor. The plugin uses TrackerSparqlStatement so queries are reusable and free of escaping issues, and there is now generic support for filters and ranges.

The MR is marked as WIP because:

  • It lacks tests
  • As you can see, there's open questions :)
Edited by Carlos Garnacho

Merge request reports