Integrating IM applications - OFI

[Mike Hearn]

On Sun, 2005-01-16 at 09:43 +0100, Marcin Krzyzanowski wrote:
> Could you explain in more detail why processing d-bus requests will 
> dramatically increasing memory pressure, I don't get it.

If you don't have a daemon to cache information then anytime you want to
build up a list of presence you have to go ask everything that might
provide it. Eg if you want a combo-dropdown widget with all your online
friends in, each presence provider must be woken up and pass its
presence data back to you. Likewise if you want to know the online state
of a particular person (because they may have switched services).

Potentially that means several instant messengers, an IRC client, phone
software etc. The code inside all of these for processing these
broadcast RPCs must be loaded [back] in from disk into memory. That
could happen everytime you read a new mail message eg Evolution/KMail
asking "are any users with this email address online?".

> You don't have to constanty send broadcasts messages you know it.

You have to do that whenever you wish to query the presence of
something. In general you want apps to sleep for as long as possible,
it's just good infrastructure design (it's for this reason that Metacity
only sends EWMH ping messages when the user actually tries to close a
window).

> what D-BUS is for then ? If there is additional daemon, specific library 
> with API then D-BUS is just unecessary overbloat.

No, DBUS provides a lot of services and infrastructure useful for
writing this sort of thing.

> every additional daemon is a problem.
> 
> First, you have to know that it have to be launched.

DBUS Activation does this automatically

> Second, you propably have to configure it

Why? Galago-daemon AFAIK does not require configuration. It's certainly
not some fundamental unavoidable happening.

> Third, You have to know when it should be launched and why.

See DBUS Activation. It's launched when it's needed and shuts down when
it's not.

> Fourth, If you don't use distribution packages sometimes (may users) 
> then you just have additional problem

DBUS is designed to be a part of the distribution. If it's not, so what?
Either they install it themselves or that user doesn't get a desktop
presence framework.

If you are talking about Galago itself, then unless your proposal is a
pure DBUS IDL spec at least *some* software will be needed, which means
packaging. 

And actually the plan for some time has been to produce Galago
autopackages, but neither piece of software is quite mature enough yet
(and we lack spare time to do it ...)

> Fifth, you should know how to stop it,

That is again a reason behind using DBUS, it simplifies a lot of the
lifecycle management. In particular I think Galago shuts down when
nothing is using it automatically. DBUS makes this sort of thing atomic
(ie race-free).

> Sixth, if a daemon is to be a middleway between apps then why D-BUS is for.

I already answered this above.

> Seventh, with daemon you'll process every request, without you don;t 
> have to (you can only process you were requested)

I don't understand this one. Of course the daemon will process every
request sent to it. That's sort of the point. DBUS provides message
filtering facilities precisely so the daemon only receives messages it's
interested in.

thanks -mike