2006/11/28, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Mon, 27 Nov 2006 14:57:50 -0500 Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>> 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.</blockquote><div> 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 </div> </div>