Re: [Deskbar] Separating UI and backend

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]