deskbar.index
Deskbar currently have an Indexer class used by the following handlers:
- Galeon (history and bookmarks)
- Mozilla (history and bookmarks)
- Epiphany (histroy and bookmarks)
- Programs (.desktop files)
The Indexer contains a dict with (string,deskbar.Match) pairs. In every one of these handlers the query() method calls Indexer.look_up(query). This call parses the query and iterates all keys in the Index returning the corresponding match for all keys that starts with query.
This Indexer class could be viewed merely as an API where the underlying storage backend is invisible. Right now the storage is a Python dict, but Tracker og Beagle (when beagle gets metadata storage capabilities) could serve as backends too. Also a plain old database could be used as storage.
Another point is that we basically only need one call into the index per query, not one for each handler like it is now (and we could also only parse the query once). A handler using the index could maybe specify this somewhere and just have an empty query() method. The Indexer.loop_up would of course need to have the results filtered according to enabled handlers somewhere.
Another benefit of such a central index is that it would also be easily made persistent, possibly given a startup boost. If moreover the backend was a real storage layer like a db or Tracker, we would also get a significant memory footprint reduction.
Other Use Cases
There was a related discussion about a Rhythmbox handler submitted to the list. Thread about a Rhythbox handler.
Database Backend
Maybe sqlite with pysqlite2 bindings. Ubuntu package python-sqlite2. This package conforms to the Python DB Spec v2.0.
Beagle Backend