Integrating IM applications - OFI

[Olivier Goffart]

Le Lundi 17 Janvier 2005 21:02, Robert Wittams a écrit :

> The applications inform the daemon *when the status
> changes*. The daemon *does not query*.

I don't think this is  good idea.
That will increase considerably the number of (unneeded) dbus call.


> Yes, lets have multiple pointlessly incompatible models. Thats the way
> forward. Shall we have an option like this:
> Make presence work properly? yes/no

If one makes a specifications for a common dbus interface , then models 
shouldn't be incompatibles.



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

We don't use DCop because it's tied to Qt, OK.
But isn't d-bus supposed to be a replacement of dcop not based on Qt ?
then, why not using dbus like we use already dcop in KDE ?

In KDE, we have designed a dcop interface (i.e. a set of dcop function that 
messengers application should have)  And in the client library there is the 
code to manage them, even with several instent messenger.  And that code is 
not big.
(see yourself http://webcvs.kde.org/kdelibs/interfaces/kimproxy/ )

We already proved it works fine with a simple interface without daemon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050118/b6fd562a/attachment.pgp