Re: [Deskbar] Separating UI and backend

[Raphael Slinckx <raphael slinckx net>]

Mikkel Kamstrup Erlandsen wrote:
> 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.

To be honest i don't want deskbar to /become/ a service. There already a 
desktop search daemon, it is called beagle. Tracker will be another one, 
with a slightly different aim.

We are just the thin layer of glue tying all together. Let's take an 
absurd look at this, why would an application do:

application --> deskbar --> beagle --> deskbar --> application
instead of
application --> beagle --> application

I think deskbr must be seen as a "power" search bar, which combine all 
existing info sources on the market, if possible intelligently.

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

Agreed, i said that to scare you :)


> > 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? 

I agree, i have nothing against the current threadedhandler, when i said 
efficient, it meant 'not having yet another python process spawn'. And i 
thought that while we're overhauling the whole thing maybe we could 
really get rid of threads.

DBus activation only opens one process when needed, and if the process 
exits, the next time the service is needed, it is releaunched, that's 
why it ould be better memory wise, but also why it would have to be fast 
to startup.

i think libsoup is part of the gnome platform, and does soap quite well. 
SOAPpy is the "standard" among python soap libs, from what i understand.

Raf.