Unifying Desktop Search

| |

Wasabi is a new proposal on FreeDesktop.org for a unified desktop search and metadata specification. I'm not qualified to comment on the specifics of the proposal, but I definitely like the vision. Over the past month I had been thinking that an API was needed so I'm pleased to see that others are already ahead of me. Getting this done is the first step towards making desktop search a truly useful feature that's good for more than just searching archives.

The Wasabi team is already collaborating with notable indexing projects such as Tracker, Strigi, Beagle, Pinot, and Recoll. If you would like to provide feedback, check out the project page on FreeDesktop.org and leave your comments on the LWN post.

Defining the Problem

I view desktop search as two pieces, an indexer and an interface. As things stand today, interfaces need to be tightly coupled with a particular indexer and are also monolithic in nature. By monolithic I mean that they search through documents, images, media, emails, and any other type of content. While a stand-alone interface with this full search capability is useful at times, it tends to miss the mark for productivity in most situations.

In addition to this monolithic search tool, other programs like email clients and photo managers also create their own index. This creates a level of duplication that adds no value to the user while consuming both processing and storage resources.

The Future

I hope the Wasabi project is successful in it's goal to create a unified API. If they can get either KDE or GNOME to support it then the chances will be good. In fact, KDE has been focusing on various API's for the upcoming KDE4 release so it should be right up their alley. After all, Phonon is doing the exact same thing for multimedia backends.

Productivity is the key benefit for any desktop search program. Unfortunately existing interfaces often require you to leave the interface you were already working in so you can run your search and then go back to the original program. This is inefficent and slow. If you have a common search API then developers can have their apps link directly to the search database and display results without leaving the program.

Two prime examples are email clients and file managers. If I want to look for an email, chances are that the best method for making use of it after being found is the email client itself. Why waste time going somewhere else only to come back immediately are finding what you are looking for?

A fully indexed and searchable file manager is my other half of the Holy Grail. It would allow you to easily confine a search within the folders that are being browsed. And once you find the desired document, a preview could instantly find and highlight the text within.

Even once the API is locked down, a lot of work will still remain. The real challenge is getting developers to use it instead of specifying an indexer or creating a custom solution. And that will be no easy feat.

Post new comment

  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
More information about formatting options