Integrating IM applications - OFI
krzak at hakore.com
Mon Jan 17 16:14:20 EET 2005
Użytkownik Robert Wittams napisał:
> >> 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.
and daemon will have to ask somebody... um.... maybe the rest of
> 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.
How about broadcast only at startup, and signals to update data directly
to specified apps ? because this is how it should work.
> >>>> 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
> >> 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.
no deameon, no d-bus with xml parsing, no glib could be more effecient
way. It's not a point. The point is, why duplicate functionality,
It's not a good way for the feature. Every specification would use
daemon to process data
Daemon as a support, optional engine, with special function whatever -
ok, but not as a integral part of multidesktop environment if is not
> 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?
> >>>> elaborate exactly what your problems with an extra process are,
> >>>> 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.
activation services is not what D-BUS is created for, it's designed to
be a message bus, not activation bus. You don't need D-BUS to activate
services, but if using D-BUS then use it not only to activate.
"D-BUS is a message bus system, a simple way for applications to talk to
> >> 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
and check why people ask that gnome menu do not update automagically...
because there is no fam running, or do not work for some reason.
Nevemind. I know it's configuration/installation problem but problem
exists and I don't care about more such problems.
> D-BUS is for activating and bidirectionally communicating with shared
> services. D-BUS is not a holy war against all other daemons.
right, but it's to be a interdesktop communication bridge, if not, why
we don't use DCOP, KDE use it and it work fair good, tested and all that
I don't get why is D-BUS there for, everything seems to be done outside
D-BUS. Simple library with few functions API is enought.
Look at wel... X Protocol based specifications... they don't have won
daemons but they could, and now you can implement it in a way you want
and be sure will work, witk gtk, with Xlibs, in any other way because
every desktop have his own best way to do it.
I don't mind to argue and don't mind to said that somebody did wrong. I
just want to be sure that nobody will ever could accuse that i've
promoted such solution.
More information about the xdg