Re: [Deskbar] Separating UI and backend

[Raphael Slinckx <raphael slinckx net>]

On Thu, 2005-10-27 at 13:57 +0200, Mikkel Kamstrup Erlandsen wrote:
> Spawning the search backend as a daemon also has the side effect of 
> swapping us out when we are unused; or what (I'm no expert on daemonology)?
> 
> Strictly about daemonizing the backend (and not dbussing as such), we 
> have on the pro side:
> 
>     + Free up ram
>     +? Ease system strain when starting up (nice=20)
> 
> Cons:
>     - Add dbus overhead both in memory and speed
>     -? Slow response when swapping in
>     - An extra *python* process
> 
> I've left out all the dbus benefits since they are too numerous to list :-)

Ok this thread (omitted for brevity) was interesting.

I don't think we are a "service", we are just a frontend. As such we
don't need to expose a dbus interface for third parties.

Benoit is wrong when he asks if deskbar can be queried by third parties
apps. Deskbar is not going to be queried, deskbar is just a gtkEntry
with a bit more functionality.

In practice, we happen do do a bit of indexing (which is redundant with
beagle is some areas) just because there are no satisfying solutions at
the moment. As i said our indexing is extremely inefficient.

As you see, having 2 python processes is too much, and we don't really
need it. Besides serializing the matches on dbus would be a pain in the
ass and useless.

About the multiple UI idea: yes we want this, for a future alt-f2
replacement, or a gnome-box-like interface. We don't need dbus for this.
We just need a clean separation of presentation layer and backend, which
is not the way it is right now. Ideally, the bonobo factory would start
and build all indexes/handlers. Other bonobo components would just be
started on demand and receiving as parameter the preloaded backends.

That way, we have snappy UIs and of multiple form, and one single python
process. (i think, i don't really know bonobo)

Anyway i think we should first focus on integrating the C to replace
current situation, and clean the backend/front end separation.


> In such an overhaul it might also prove worthwile to convert
> AsyncHandler to a daemon, to get it out of process to avoid gtk
> threading madness (stop smiling Raphael ;-P)... Currently there's only
> the google-live handler so we won't be spawning daemons left and right
> anytime soon...

That idea, i like it.

What i propose is the following:
Remove the threaded Asynchandler from deskbar, that way no more threads.
Make a subclass of Signalling Handler that will use dbus.

This handler will take one parameter, the name of an interface, example
org.foo.GoogleLive.

When queried this subclass will invoke the dbus method
org.foo.GoogleLive with the string as parameter, and will return the
relavant parameters of the match, converted by the handler in a proper
deskbar Match.

That way we can use the dbus activation feature, and the external
program will be launched automatically.

Example API:
DbusAsyncHandler(SignllingHandler):
	def __init__(self, interface):
		self.interface = interface
	def query(self, string):
		self._query_dbus(string)
	def _query_dbus(self, string):
		dbus_remote_call_async(self.interface+".query", on_dbus_answer)

	def on_dbus_answer(self, *args):
		self.emit('new-match', parse_results(args))

GoogleLiveHandler(DBusAsyncHandler):
	def __init__(self):
		DBusAsyncHandler.__init__(self, "org.foo.GoogleLive")
	def parse_results(self, url ,snippet, title)
		return GoogleLiveMatch(url, snippet, title)

And in a new process, either python or C, in pseudo code:
register_dbus_interface('org.foo.GoogleLive')
request_dbus_name('org.foo.GoogleLive')

register_method('query', string)
query(string):
	results = do_blocking_xmlrpc_stuff()
	return pack_results(results)

For efficiency reasons, the process should be written in C, i think it's
easy enough to do a C program doing fast xmlrpc with some helper libs.

Stick some config files in /usr/share/dbus-1 to have autoactivation, and
that's done.

Comments?

Raf