Integrating IM applications - OFI

[Marcin Krzyzanowski]

Użytkownik Robert Wittams napisał:
>> and daemon will have to ask somebody... um.... maybe the rest of
>> applications. somehow.
> 
> 
> Are you dense? 

Sorry but I can't discuss with you anymore.

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

heaven :)

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

answer could be : use KDE. But it have no sense, sorry.

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

No.

> Why on earth would you make a system based on D-BUS but use some other system for 
> activation?

Isn't it what you suggest ? sorry if I misundestand.

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

propably you right, I just keep in mind slackware users all the time.. I 
shouldn't.

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

but we could write dcop-like/compatibe bus propably.
All the time I say that D-BUS should be used.

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

and most things can be done with this one daemon wihout additional 
uneccesary daemon for every extension.


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

I don't mean it's to heavy, it's just unecessary.

code of additional daemon as a part of specification is to much - you 
shouldn't force to use daemon as a integral part of specification which 
may be commonly used.

-- 
Marcin Krzyżanowski