Integrating IM applications - OFI

[Marcin Krzyzanowski]

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

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

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,
decrasing usability.

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

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

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
one another."

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

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


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.

that's all.


-- 
Marcin Krzyżanowski