Re: [Deskbar] Separating UI and backend

[Mikkel Kamstrup Erlandsen <kamstrup daimi au dk>]

On Sat, 2005-10-29 at 14:55 +0200, Raphael Slinckx wrote:

> 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.
> 
With a dbus interface we could /become/ a service. As an added bonus a
dbus interface will make it possible to do a transparent transition to a
C backend at some point. Create a desktop search daemon (is that what
Tracker is?).

I'm not necessarily for this... Just pointing it out.


> Besides serializing the matches on dbus would be a pain in the
> ass and useless.

No and no. It's only a pain if we want to put icons on wire (that's a no
go). Just putting icon names makes more sense. Useless? Restricting
usage to deskbar yes, but not if we go for a global desktop search
interface.
I sketched out an architecture today and it seems to be quite doable.

> That way, we have snappy UIs and of multiple form, and one single python
> process. (i think, i don't really know bonobo)
> 
He, I can't claimto know my bono-bible by heart either :)

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

Granted.

> 
> > 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 ...
> 
> That idea, i like it.

Surprise! The chock! :)

> That way we can use the dbus activation feature, and the external
> program will be launched automatically.
> 
> Example API:
> DbusAsyncHandler(SignllingHandler):

  <snip>

Seems reasonable.

> 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.
> 
Actually the current implementation (of async handler) is also kinda
efficient... There are no extra threads running when the deskbar is
idle. They are only spawned on demand.

Doing a Google-Live daemon in C is pretty low priority in the near
future. Anyway, SOAPpy appears to be quite standard among distros. Are
there any soap libs that are relatively safe to assume available? 

Cheers
Mikkel