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

[Jos van den Oever]

2006/11/19, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> In a stateless lib you don't have to do any bookkeeping, the list of
> providers would be created when the app asks for it. Here's a short sketch
> of how I figure the workflow:
>
> App: calls lib.getSearchProvider (interface_name)
> lib: emit a SearchProvidersSpeakUp(iface_name) signal over
> dbus
> SearchProvider: return its object path to the lib
> lib: select a provider from the candidates if there's more than one
> lib: return candidates object_path
> App: dbus connect to iface, object_path
>
> Does this make sense? What I really wanna do is push as much book keeping to
> dbus itself, since it already does a great deal of what we actually need...

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.

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.

Cheers
Jos