Tracker 1.x Roadmap
- Fix all the compile warnings in 'master'.
Decide who the website and documentation is *for*, and organise it appropriately
- Make the functional-tests all pass reliably
- Convert them to installed-tests so build.gnome.org runs them
- Add some more realistic functional tests
- Integrate with some desktop-wide automated testing project
Automatic indexing of removable devices is disabled by default, because it can cause lots of unexpected IO usage if a device with lots of files is connected.
It would be great if users could 'opt in' to scanning devices when connected.
Bug https://bugzilla.gnome.org/show_bug.cgi?id=680834 has a patch for this which needs a little reworking.
Sandboxing / isolation
Historically Tracker has taken an approach of storing all of the user's metadata in one place, and any process run by that user can access any of it. Now Flatpak is taking off, this no longer makes sense. For example, a sandboxed Gnome Documents should only be able to access nfo:Document instances in locations that the user has allowed it to see.
We plan to move all the parts of Tracker that an app needs to inside the sandbox. This is possible to do today, but rather unwieldy because of various assumptions in the Tracker code.
Sandboxed apps can make their content searchable using the SearchProvider interface, which is already widely used as that's how Gnome Shell provides search results. This is less powerful and possibly slower than the current SPARQL query interface that Tracker currently provides.
Sandboxed apps could also make their data available to the session-wide Tracker daemon by exporting the data in an RDF serialization format on request. This would mean fast and complex queries are still possible, but at the cost of duplicating the data inside and outside the sandbox.
The big advantage of this approach is that it fits within the existing sandboxes. The alternative approach of opening the session-wide Tracker store to every sandboxed app and trying to enforce access limits within SQLite would make the tracker-store process become security-sensitive as any bugs in the access control code (which we would have to implement from scratch) could allow private data to be seen by sandboxed apps.
To implement this, we need to...
- make tracker-store usable as a library as well as a daemon
- make tracker-miner-fs usable as a library as well as a daemon
- update apps to use the libraries and to ask the user to "opt in" to monitoring locations: a "search configuration" portal is needed...
Previous discussion: https://mail.gnome.org/archives/tracker-list/2016-January/msg00029.html
Gnome Music will need this at some point?
Could be implemented with:
- something else
Splitting up tracker.git into separate projects
- libmediaart done already
- evolution plugin, firefox plugin, thunderbird plugin, can go somewhere else
- tracker-needle and other GTK+ programs could go in a separate tracker-ui.git
- - need a way of packaging the ontologies and tracking version dependencies
Focus on being a metadata index / cache
- journaling feature was added to protect against corruption when things
- crash, and it works well. But if Tracker focuses on indexing/caching rather than being a primary data store then it's not necessary.
- Remove deprecated classes
- Remove glue/internal classes (tracker: properties and classes)
- Choose between NCAL/SCAL and remove one of them.
- Decide whether to continue with the abandoned NEPOMUK ontologies, or
- 'fork' them ourselves, or use something totally different.
Better file system monitoring
Currently tracker-miner-fs uses 'inotify' kernel API. This isn't ideal because you can't do recursive watches with inotify.
FANotify is one option. FANotify does recursive monitoring, which is great, but can only monitor the root directory of a given mount (so lots of unnecessary events will probably be emitted).
A minimal daemon running as 'root' that can filter the notifications from the kernel and forward them to unprivileged processes (i.e. tracker file system miner) would be another solution. But it would be nice to solve this without needing to add a new system service.
The Gnome Online Miners could make use of the new TrackerEnumerator API, and reuse most of the code in tracker-miner-fs instead of using their own miner base class.
They could possibly also use the Grilo API to access remote web services instead of using their own C code.
Functionality should stay the same but hopefully we can reduce the amount of code in gnome-online-miners.git.
Operating without an index
Using the tracker-sandbox tool it's possible to search files without having to first configure Tracker's indexing locations.
This is useful functionality, and it would be neat to expose it in tracker-needle or some other search tool.
Tracker 2.x Roadmap
Remove IgnoreNextUpdate completely; it is totally broken and not used.
- Remove INSERT OR REPLACE, which is non-standard SPARQL and isn't used in tracker.git any more (outside tests/)
Old TODO items are available in the Projects/Tracker/Roadmap/Old/0.x