There’s a few plans in the boiler for Tracker:
Splitting core from miners
Tracker is usually deemed a “metadata indexer”, although that’s just half the truth. Even though Tracker could be essentially considered that in its very early days, it made a bold move back in 0.7.x to using Sparql as the interface to store and retrieve this metadata, where both the indexers and the applications using this metadata talk the same language.
So in reality, the storage and query language are useful by themselves. As per the plans, you’ll now have to distinguish between:
– Tracker the RDF store, and
– Tracker miners, the infrastructure and binaries to translate a number of entities (be it files or whatever) into Sparql, using the first acceptation for storage
Making standalone Sparql endpoints possible
At the time of moving to Sparql, Tracker was conceived as a global store of deeply interconnected data, Nepomuk seemed the most obvious choice to represent the data for indexing purposes and client isolation was basically left to 3rd parties. However times change, sandboxing is very present, and Tracker’s global store don’t help with it.
Based on initial work from Philip Van Hoof, quite some shuffling has been going on in wip/carlosg/domain-ontologies to make multiple Sparql endpoints (“database connections” in non-fancy speak) possible. This will allow applications to use private sparql endpoints, and possibly using other ontologies (“schemas” in non-fancy speak) than Nepomuk. The benefits are twofold, this will be a lot friendlier to sandboxing, and also increments the versatility of the Tracker core.
Switching to Semantic versioning
This change was suggested some time ago by Philip Van Hoof, and the idea has been growing in me. Tracker has usually had a longstanding backwards compatibility promises, not just in terms of API, but also in terms of data compatibility. However, bumping the version as per the GNOME schedule results in multiple stable versions being used out there, with the patch backporting and bug management overhead that it implies.
In reality, what we want to tell people (and usually do!) is “use latest stable Tracker”, often the stuff is already fixed there, and there’s no reason why you would want to stick to a stable series that will receive limited improvements. I do hope that semantic versioning conveys Tracker’s “later is better” stance, with some optimism I see it standing on 2.y.z for a long time, and maybe even 2.0.z for tracker core.
But versions are like age, just a number :). Tracker 2.x services and client side API will foreseeably be backwards compatible with 1.x from the reader standpoint. The Tracker core could be made parallel installable with 1.0, but I wouldn’t even bother with the high level infrastructure, 2.x will just be a better 1.x.
But this doesn’t mean we jump the GNOME unstable cycle ship. IMHO, it’s still worth following to let newly introduced code bake in, it just won’t result in gratuitous version bumps if API changes/additions are not in sight.
Code and API cleanup
In the more active past, Tracker had a lot code accretion while trying to get the buy-in, this included multiple miners, extensions and tools. But it was never the goal of Tracker to be the alpha and omega of indexing in itself, rather to have applications update and blend the data for their own consumption. Fast forward a few years and the results are mixed, Tracker got an amount of success, although apps almost exclusively rely on data produced by Tracker’s own miners, while most of these extensions are bitrotting since much of the activity and manpower went away.
Sam Thursfield started doing some nice cleanups of maemo/meego specific code (yes, we still had that) and making Tracker use Meson (which indirectly started tiptoeing some of that bitrot code). Several of these these extensions implementing Tracker support shall just go to the attic and should be done proper, it will at least be the case with nautilus thanks to Alexandru Pandelea’s GSOC work :).
But the version bump and code split is too good of an opportunity to miss it :). Some deprecated/old API will also go away, probably none of which you’ve ever used, there will be some porting documentation anyway.
Thrilled that you picked up on the idea of domain ontologies. I think this will in a few months, maybe years, be very useful for many application developers. Both commercial as open source / free software. We know that Tracker is in use in area’s like storage and NAS, vehicle infotainment, digital TV setup boxes. This will I believe open the doors to many more similar use cases.
Somewhere deep in my hart I will always love GNOME. Maybe not for the decisions it, as an organisation, made. But from a philosophy (a desktop that is free, as in free beer). But you know I’ll never stick with just a free desktop. Nepomuk was ideal for a desktop world: one ontology and one graph store to rule all applications of this singleton desktop. But this is not the reality of computing. It was never supposed to be. It won’t be. We have multiple devices, multiple accounts (users), multiple contexts, multiple use-cases. For privacy, for example, we’ll have multiple preferences (depending on multiple choices). Metadata is all about privacy. As developers of the open source metadata solution, we should allow many possibilities. This way we put it in the hands of the metadata users, not in the hands of the metadata consumers. If you know what I mean.
Wow, your announcements in this blog are all awesome. Thrilled that Tracker’s research and development continues.
And a tip of the hat for the semver. Semver is a good choice. When suddenly a lot of wip/branches happen, with a lot of people helping out: consider gitflow.
Awesome,
Philip