2006/11/20, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2006/11/19, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>: > 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.</blockquote><div> 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).  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> 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.ListActiva<div>tableNames() and some black magic to check what interfaces where provided by the non-running activatables - without activating them!  </div>Cheers, Mikkel </div></div>