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

[Mikkel Kamstrup Erlandsen]

2006/11/28, Magnus Bergman <magnus.bergman at observer.net>:
>
> 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.


Yes. I suggest this on the WasabiDraft2 wiki page. However this is technical
concerns I think we need not worry about at the moment. At some point in the
future we can implement a management interface but the dbus interfaces to
the search engine(s) does not need to reflect this. Let's stick to what we
can "implement" by API specifications only. Unless there is some obvious
deep connection I have missed.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061128/a9c3abde/attachment.htm