Integrating IM applications - OFI

[Robert Wittams]

> and daemon will have to ask somebody... um.... maybe the rest of
> applications. somehow.

Are you dense? The applications inform the daemon *when the status 
changes*. The daemon *does not query*.

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

"specified apps". So every single app that provides presence info now 
has to know about every single app that wants it. Thats efficient.

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

What on earth are you talking about?

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

Yes, lets have multiple pointlessly incompatible models. Thats the way 
forward. Shall we have an option like this:
Make presence work properly? yes/no
> 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."
> 
> (...)

Are you now actually denying that D-BUS handles activation? Why on earth 
would you make a system based on D-BUS but use some other system for 
activation?

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

Yes, and lets mention that people ask why the sky is blue here as well. 
Its irrelevant, but who cares?

People who are
a) Not able to set up their systems
b) Choose not to use an easy distro

Can never dictate fundamental design decisions. They are irrelevant to 
the discussion.

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

yes, but, here is an unrelated fact that has nothing to do with your 
point. We all know why we don't use DCOP: it is tied to Qt, which is 
licence incompatible with a lot of desktop software. The fact that you 
personally don't understand D-BUS isn't a good reason to dismiss it.

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

Do you really not see the point in a common message bus? We are talking 
about multiple processes here... DBUS is the substrate for multi-app 
protocols. That doesn't mean it shoudl subsume the functionality of 
every single app that uses it.

> 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 honestly have no idea what you are trying to say here.

Are you saying that the X Protocol does not have a daemon? What do you 
think that the X Server is? It isn't a good idea to store this kind of 
state in the X server ( think about the common situation where all of 
the clients are on one machine and the X Server is on another. Look at 
the clipboard thread for examples of how this can bite.)

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

This is incoherent. You are promoting a solution that has been pointed 
out to be sub optimal, and so far the only points that have been made 
from your side are:
  "ligth-weight manner  :-)" as if that constitutes some kind of 
explanation.
  a lack of knowledge of D-BUS.

In your next rambling reply, please address the following point directly:
Why is a single extra process heavyweight? To help in your merry quest, 
keep in mind this fact: processes are cheap. Especially if they are long 
running.

Robert Wittams