Integrating IM applications - OFI

[Robert Wittams]

 >
 >>
 >> Could you explain in more detail why processing d-bus requests will
 >> dramatically increasing memory pressure, I don't get it.
 >>
 >> You don't have to constanty send broadcasts messages you know it.
 >>


Every client needs to remain paged in. This means the minimal working
set of pages for the event loop & dbus handling bits of every single app
that wants presence information ( and we want it to be universal,
remember?) needs to remain in physical ram. If you don't send broadcast
messages, not every app will know the state, so they'll have to ask
someone... um, who could they ask? Maybe a daemon.

The other option is for every single app to know what presence info
every single other app needs. This seems to lead to a huge amount or
duplication( ie memory pressure), not to mention its incredibly hard to
debug this with hetrogenous clients.


 >>>>
 >>>> I think you're assuming dropping the daemon will improve
 >>>> system performance. It won't. It will make it worse.
 >
 >>
 >>
 >> what D-BUS is for then ? If there is additional daemon, specific 
library
 >> with API then D-BUS is just unecessary overbloat.


Why are you so convinced that daemons are always more "heavyweight" and
bloated than libraries? If you have state that has
Multiple frequent writers
Multiple infrequent readers

Then a daemon ( an autonomous queryable lump of state) is almost always
going to be more efficient than multiple shared lumps of state, each of
which must be updated on every write.
If we want to support pervasive presence info, it seems to fit into this
model... The only vaguely reasonable library model involves mmap'ing
shared areas, and nightmarish locking & network transparency issues.
Lets leave mmap'ing fun to database servers and read only caches for now.

   This is starting to remind me of the "ASM is always faster than C is
always faster than C++ is always faster than Lisp( etc) " wars ...


 >>>> If it's not performance you're concerned about then what is it? Please
 >>>> elaborate exactly what your problems with an extra process are, 
because
 >>>> right now I don't see any obvious reasons behind it, just a vague
 >>>> feeling that it's unnecessary and heavyweight.
 >
 >>
 >>
 >> every additional daemon is a problem.
 >>
 >> First, you have to know that it have to be launched.

This is exactly what D-BUS is for : look at all the activation
infrastructure. When a service is requested it is activated. Go and read
the D-BUS lists, it is not worth repeating a whole scad of
misunderstanding here.

 >> Second, you propably have to configure it

Thats an implementation issue. Nothing to do with daemon vs. library. I
doubt a config required daemon is going to be very popular.

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

See first point.

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

People who have the combined attributes of not using distro packages and
being too clueless to read documentation are not the driving target
audience for the majority of fd.o

 >> Fifth, you should know how to stop it,

A daemon can have some policy to die after not being used for some time.
In this case it seems fairly pointless to do so : maybe after every
single presence-caring or providing app has exited. If this becomes an
issue, the pervasive presence thing has pretty much failed. Ie it didn't
even manage to get the screensaver to care!

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

Look, a daemon doesn't have to be run by init. It is just a process
running for the user to provide services to other apps. It is an
*implementation issue*. D-BUS is not going to include every bit of
functionality itself in the bus process. And promiscuous messaging is *a
waste of resources*.

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

This is incoherent. I'll just mention that the daemon only has to
process requests that it knows will be useful for its clients. It can
throw away or not even listen for other ones : eg look at fam or
gam_server.

   D-BUS is for activating and bidirectionally communicating with shared
services. D-BUS is not a holy war against all other daemons.

Robert