[dot] FOSDEM 2005: Desktop Search Interview

[Dot Stories]

URL: http://dot.kde.org/1109163846/

From: Jonathan Riddell <>
Dept: they-look-here-they-look-there
Date: Wednesday 23/Feb/2005, @14:04

FOSDEM 2005: Desktop Search Interview
=====================================

   The schedule for the KDE developers room talks at FOSDEM
[http://www.fosdem.org/2005/index/dev_room_kde/schedule] is now online. 
Our final interview with the speakers is with Scott Wheeler who will be
giving a talk titled KDE 4: Beyond Hierarchical Data, The Desktop as a
Searchable Web of Context.  FOSDEM [http://www.fosdem.org] is this
weekend, see you there.

      Please introduce yourself and your role in KDE.

     I feel like I've been asked this question enough times that I
should have an exciting answer by now.  But well, I wrote JuK and TagLib
as well as a couple of other small applications in KDE CVS and do some
work on a handful of things in kdelibs and elsewhere across KDE.

     What kind of search capabilities do you think a modern desktop
should have?

     Well, I think I'd like to step back a bit first and look a little
at the problem  and the problem isn't a lack of a search tool, the
problem is that it's hard to find things.  Search tool or no, all of the
ideas flow from the idea of solving the problem rather than just
creating a new tool.  So, in a sense, I don't think a modern desktop
should have a search tool; I think a modern desktop should make it easy
to find stuff  we're then left with how to get there.

     And I suppose with all of the buzz around search tools these days
people have a much more concrete idea in mind when they hear about
searching on the desktop.  But such wasn't the case when I started
kicking these ideas around a while back.  Spotlight was announced a few
days after I'd submitted my abstract for the KDE Developer's conference,
Beagle was relatively low profile, Google for the Desktop and its
successors hadn't entered the scene yet, etc.

     So, I think  fundamentally "what sort of search should the desktop
have" is almost the wrong question.  "How should we make it easier to
work with the data we accumulate on the desktop?" is closer to the right
question.  I think search is just part of the answer.

     Where did the idea of integrating a search capability throughout
KDE come from?

     Well, a few things actually.  It mostly came from not being able to
find things and asking some fundamental questions about how we organize
and access information on the desktop.  The first step  and this is tied
up with the first part of the name of both this talk (which is related
to the one that I gave at Linux Bangalore) and the one at the KDE
conference this summer  is that hierarchical interfaces simply don't
make sense in a lot of cases.

     When I started looking around for examples of how this had played
out in other domains of information, the most obvious example was the
World Wide Web, where we've already moved from hierarchical interfaces
to search based interfaces.  It seemed logical that we could learn from
that metaphor.

     On the technical side of things I'd just written the listview
search line class (used in JuK) that's now fairly prevalent in KDE that
makes filtering of information in lists much easier, so that played into
things too.

     What do you think of other search tools such as GNOME's Beagle and
Google's Desktop Search?

     Well, they're fundamentally different in scope.  Again, right now
the term "desktop search" actually means something; that wasn't really
true when I started working on these ideas this summer.  So while there
are some things in common, they're really pretty different approaches.

     Beagle, Spotlight, Google for the Desktop, and their relatives are
more interested in static indexing and search through that information. 
That's kind of where I was at conceptually early this summer when I
coded the first mock-up.  Since then however the ideas have moved on
quite a bit and I think we've actually got something rather more
interesting up our proverbial sleeves.  (I should note however that I
think the Beagle group is doing fine work, but it's something pretty
different from what I'm interested in.)

     The first difference is that this is a framework, not a tool. 
Beagle has some elements of this, but it's still not integrated into the
core of the desktop.  Google for the Desktop is mostly just a standalone
tool from what I know of it.  Honestly I think it's really below the
level of innovation that I tend to expect from Google.

     What we're now looking for in the KDE 4 infrastructure is a general
way of linking information and storing contextual information  that
information can come from meta-data, usage patterns, explicit
relationships and a host of other places.

     There won't be a single interface to this set of contextual
information; we'll provide some basic APIs for accessing the components
in KDE applications, but we're quite interested in seeing what
application authors will think to do with it.  Really I think they'll
surprise us.

     We're looking at everything from reorganizing KControl to make
search and related items and usage patterns more prevalent to annotating
mails or documents with notes to reworking file dialogs.  Really the
scope is pretty broad.

     Do you think Free Software solutions from KDE and GNOME can compete
with the likes of Google and Microsoft?

     Sure.  I mean  I don't think the ability to compete with commercial
players is significantly different with desktop search than it is with
other components of the desktop.  And honestly I think we've kind of got
a head start here.

     Has there been any progress on planning or coding search into KDE
yet? Is anyone helping you? What problems are you facing?

     There have been a number of cycles through some API and database
design sketches.  But right now we tend to write code and as soon as
it's done we've realized the flaws in it and start rewriting.  This will
probably continue for a while, but I think we'll be able to have
something pretty useful in KDE 4.

     There are a number of folks involved in discussion of these issues
from various sub-projects inside of KDE.  Thusfar it's been mostly
myself and Aaron Seigo banging on the API, but others have contributed
to the discussions.

     I think the biggest problem that we're dealing with is moving from
the abstract set of ideas that we're working with into real APIs  trying
to keep things general enough to stay as extensible as we'd like them to
be, but not so lofty that they're convoluted and useless.

     What technologies do you plan on using, e.g. which database?

     Well, we've gravitated towards Postgres, but mostly because of
licensing.  Other than that, well, uhm, we're using Qt.  The Qt 4 SQL
API seems much improved, so I've kind of been mentally stalling on
really finishing up the current code until I can just work with that
since otherwise everything would just have to be rewritten in a few
weeks.

     Is the KDE search tool likely to be cross desktop compatible so we
could have a common base with Gnome?

     Well, again, this really isn't about a "KDE search tool" -- and the
chances of it being GNOME compatible out of the box aren't particularly
high.  That said, as the data store will just be a Postgres database and
ideally we won't have to use too many complex serialized types, there
wouldn't be a reason that a GNOME frontend couldn't be written.  But
generally speaking I'd like to get the technology laid down and then see
if we can convince others to adopt it rather than the other way around.

     What does the project need most now?

     Time.  And I mean that in a few ways  we need time to finish
fleshing out the ideas, time to let the stuff mature inside of KDE and
well, the couple of us working on it could use more time for such.  But
really as most of the framework for things like metadata collection and
whatnot are already inside of KDE this won't be a huge project from the
framework side.  What will take a good while will be porting over
applications to use it where appropriate.