Tracker Roadmap and Wishlist

Roadmap

Tracker doesn't have a full time development team. The maintainers welcome your contributions to improve the project and will volunteer our time to review them, but a formal roadmap would be dishonest -- this blog post explains why.

Our general goals are...

• to fix open issues in Tracker core and Tracker Miners.

• adding features needed by apps that use Tracker

• improving performance, and reducing marginal carbon emissions (as explained in this presentation)

• improving test coverage

Wishlist

The maintainers use GitLab issues for issues which are small and/or high priority. This wishlist records things we would like to see, but which aren't actively being worked on. If you're interested in working on something here, please contact us -- we would love to help you get started.

New search designs

Plans from https://gitlab.gnome.org/GNOME/tracker/-/issues/385#note_1636773

Support syncing data across machines

See: https://gitlab.gnome.org/GNOME/tracker/-/issues/393

New name(s)

"Tracker" has negative connotations around spyware and advertising which weren't really a concern in 2006 when the name was chosen.

Discussion: https://discourse.gnome.org/t/should-tracker-be-rebranded/10937

Ideas:

• rename libtracker-sparql to 'sparqlite' -> requires checking with sqlite team that there's no trademark issue

• rename IRC channel to 'gnome-search' or 'desktop-search'
• rename tracker-miner-fs to ... something

A new logo

We have a new logo design here: https://gitlab.gnome.org/Teams/Design/library-icons/-/issues/1

The website does not use it, and should be updated.

Content apps need to index custom locations

See: https://gitlab.gnome.org/GNOME/gnome-music/-/issues/69

Totem desires a similar change, and Photos may also.

Help when formulating SPARQL queries

It's easy to accidentally write SPARQL queries that return no matches. A simple example:

SELECT ?url ?mime {
  ?url a nfo:FileDataObject ;
     nie:mimeType ?mime .
  FILTER (tracker:uri-is-descendant('file:///home/sam', ?url))
}

There are two problems with this query -- 'nie:mimeType' should be 'nie:isStoredAs/nie:mimeType'; and 'file:///home/sam' should be <file:///home/sam>.

Writing queries would be better if Tracker warned the user in case of mistakes like these. SPARQL itself allows queries to return unbound variables, but I think we could (optionally) warn in these cases.

Index the whole home directory

Tracker defaults to indexing a limited set of directories. This leads to the problem described here where search will not return any results for filenames in ignored locations.

We don't content-index the whole home directory by default, because...

• first-time indexing so many files may be expensive

• the index may grow very big (can we store 1,000,000+ nfo:FileDataObject resources comfortably?)

• media content from unexpected places may be indexed, e.g. a video game folder containing assets in .mp3 and .jpeg format that Tracker processes if they were part of the user's music and photo collection.

We should investigate if there's way to do 'filenames-only' indexing across the whole home directory, so that search can return all the user's files even if it doesn't do full-text search on everything.

Investigate `serd` library for Turtle reading and writing

Tracker contains code to read and write Turtle and TriG syntax. The https://gitlab.com/drobilla/serd library is a small, fast implementation that could do this for us.

Tracker's Turtle parser reports errors without line number information. Serd has better error handling.

Implement XESAM/Recoll query language

The tracker CLI currently supports SPARQL queries and keyword searches. Other tools, such as Recoll support a more powerful syntax (see this documentation for example). We could implement the same thing in Tracker.

SPARQL templates

Generating SPARQL queries through string concatenation is common and problematic. Escaping of special characters needs to be done correctly by the caller. And the query is hard to read when spread throughout code.

A better approach is to write the query as a template, which can later be expanded. The TrackerSparqlStatement function goes some way towards this, but it's quite limited:

• Only works for SELECT, not INSERT / UPDATE
• Only works for simple literal values, not lists or triples
• Does not work for GRAPH or SERVICE names

All of these limitations are because TrackerSparqlStatement maps directly to sqlite3_prepare(), so the underlying SQL query cannot change between statements.

In GNOME Photos we added a separate 'sparql template' class, using {{ }} template substitutions. This worked well and could be expanded. We need to avoid confusion with TrackerSparqlStatement, however.

Update Tracker wikipedia page

It's rather out of date. See https://en.wikipedia.org/wiki/Tracker_(search_software)

Old TODO items are available in the Projects/Tracker/Roadmap/Old/0.x

CategoryRoadMap

---