simple search api (was Re: mimetype standardisation by testsets)

[Magnus Bergman]

On Mon, 27 Nov 2006 14:57:50 -0500
Joe Shaw <joeshaw at novell.com> wrote:

> Hi,
> 
> On Thu, 2006-11-23 at 16:26 +0100, Mikkel Kamstrup Erlandsen wrote:
> > The situation at hand is that we have a  handful of desktop search
> > engines, all implemented as daemons, both handling searches and
> > indexing. 
> 
> Yeah, but this situation isn't realistic.  The user should never be
> running more than one search system at a time.  When they type in
> "vacation photos" they don't care which engine is being used
> underneath, they care about getting their vacation photos.

That certainly depends on what you call realistic. Is it only realistic
that users would want (or should be able) to do such simple searches? I
think it's realistic to imagine that there can be different search
engines which are good at different things. Perhaps one is good at
finding media files by their tags. One that is good at finding relevant
information from fuzzy terms. And maybe one that gathers information
from the whole local network. Even if this isn't very close at hand, I
don't think it's right to assume that nobody would want this, ever.

> To ensure timely indexing of the user's data in the background, these
> search engines really have to be started as part of the user's session
> and not on-demand.  (Although a non-indexing searcher like "grep"
> would be fine on-demand.)  I want all of my vacation photos to be
> indexed by the time I have to search for them.

As I mentioned before. There no reason to assume that the daemon doing
the indexing is directly involved then the searching is done (some
search engine use the same daemon for both things, some don't). How and
when to do the indexing can be decided be each search engine
implementation.

> > Having an extra daemon on top of that handling the query one extra
> > time before passing it to the search subsystem seems overkill...
> > Ideally I see the daemon/lib (or even executable) to only be used
> > as a means of obtaining a dbus object path given a dbus interface
> > name (" org.freedesktop.search.simple").
> 
> I feel like I missed something in this thread thus far, but why is a
> library or separate daemon necessary?  Why would the engine not simply
> grab the "org.freedesktop.search.engine" (or whatever) name at startup
> if it's available?  If nothing has the name, you could activate a
> grep-based fallback or something like that on-demand.

At least I see it there has to be some kind of daemon if there is a
dbus interface. But some search engines don't have a daemon (involved
in the searching that is). In those cases the searching can be done in
process (and you need neither daemon nor dbus). But a daemon could
be created to wrap those search engines, and it could provided a dbus
interface.