Integrating IM applications - OFI
krzak at hakore.com
Mon Jan 17 23:19:19 EET 2005
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?
>> 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
> 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?
> Why on earth would you make a system based on D-BUS but use some other system for
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
>> 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
>>> 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
> 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
> 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
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.
More information about the xdg