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

[Mikkel Kamstrup Erlandsen]

2006/11/20, Jos van den Oever <jvdoever at gmail.com>:
>
> 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.


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).


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.

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.

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.

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.ListActivatableNames()
and some black magic to check what interfaces where provided by the
non-running activatables - without activating them!

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