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

[Jos van den Oever]

2006/11/20, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > The question is: how long should you wait for search engines to
> > register themselves before doing any searching? I you have a manager,
> > you get one reply, this you know. In your scenario, you do not know
> > how long you have to wait. If a search engine is currently swapped out
> > it may take more then a second for it to respond. So the latency of
> > the first operation is the maximum latency you expect a search
> > application to have.
>
> Wont the result be the same if the search manager is swapped out? Also apps
> could easily connect to dbus services async or in an idle call, when I write
> user end apps I usually do this to reduce any potential waiting (it is very
> fast in 99% of the cases though).
No, if the searchmanager is swapped out, it might be slower than
usual, you know that if it responds you are ready. You wait for 1 call
only. If you search for searchengines, you don't know how long you
have to wait. You are right that if you do this on initialization,
it's less of a problem. However, I think the waiting time in your
scenario could be seconds ,which is too long for a desktop app.
Also, I already wrote the searchmanager, it's c, it's light and it
will save on code on the different search engines. Also, it is
designed in such a way that it is not required. The different search
engines can also implement the searchmanager interface and yield to
the searchmanager when it comes up.

> > This is also the argument against introspection. The number of objects
> > may be very large and thus introspection can take forever, again
> > because you dont know if an app is there.
> >
> > The dbus daemon itself does not cache the info we're looking for, so
> > we need to cache it somewhere. There are two options:
> > - a library that reads from a file in which search engines write that
> > they are available and under which object
> > - a daemon that has this info
> >
> > The scenario with the file is awkward for a number of reasons: which
> > language should the library be written in? and what to do if an
> > application crashes without removing it's name from the list? The
> > daemon can be automatically updated when the name of the application
> > is unregistered.
>
>
> The whole idea with the lib is to have a stateless implementation, thus no
> files on disk to cache stuff. Basically I just want to go through your whole
> registration step each time an application requests a specific interface.
> This way it'll always be up to date.


> If the search engine dies (like in crashing and not shutting down cleanly)
> underneath the running application it would have to re-request an object
> path for the interface. As far as I can tell it is the same with the daemon,
> or?
>
> Language? C or C++ I guess, no qt or glib. Like your search manager.
yep

> When I think about it the memory issue is less important since linking
> against a light shared lib or having a light daemon run will probably give
> roughly the same small memory overhead.
>
> Looking through your code it seems that a lot of it would work in a lib too
> - it is going to perform almost the same stuff anyway... As you may guess
> I'm still not totally hooked on the daemon idea - I'm still not rejecting it
> either.
That's good because it's a decision we'll be stuck with for some time.
Actually, I think that if you want to save on daemon, this 'caching'
functionality can be done for many different interface types not just
for searching. But this is not a problem now. The functionality of the
searchmanager can be merged into a 'dbusactiveinterfacecache' daemon
later on.

> Another issue is D-Bus activation. Should we even assume the search daemon
> is running when we look for interface providers? Tracker, for instance, can
> be started by dbus activation - I don't know about Strigi, but Beagle can't
> do this I think. D-Bus activation makes a lot of sense I think. Some users
> simply don't use searching, and with activation they get zero-nadda-no
> overhead if they don't do searches.
No we shouldn't. As the demo search engine in the code shows, the
search engines can easily add a simple version of it that only points
to the search engine itself and yields to the search manager when it
comes up.

> I'm not 100% sure how to handle the whole deal if we take dbus activation
> into account. Then we'd have to do org.freedesktop.DBus.ListActiva
> tableNames() and some black magic to check what interfaces where provided by
> the non-running activatables - without activating them!
Yes, if you want to let the library or daemon start apps then we need
a config file for that.

Cheers,
Jos