So I went to the OpenCDI* Telepathy meeting in Brussels yesterday(ish), here
are the main points from the meeting:
* Open Communication Desktop Interface
Attending: Eva Brücherseifer (KDE/BasysKom - openCDI), Stefan Eilers
(BasysKom)
myself, Olivier Goffart
Rob Taylor, Rob McQueen and Philippe Kalaf (aka Burger) from
Collabora Ltd
Various guys from Nokia (sponsoring Collabora to work on telepathy)
Stichting NL.net (sponsoring BasysKom to work on OpenCDI)
Various Debian people and Raphael Slincx who I think does something
with
DBUS.
Asterisk people were invited but unable to attend
*) Collabora presented the Telepathy framework which is a set of DBUS
interfaces which offer standardized interfaces to interact with IM/VoIP
systems. Think like KIMIface but with relatively more control than presence
emphasis. telepathy.freedesktop.org is the resource but is not quite up to
date.
Goal is to make it very easy for all kinds of apps to use various types of
messaging. Collabora are mainly emphasizing Jabber/VoIP but realize
proprietary IM systems are part of real world messaging.
Telepathy would consist of 3 layers of processes connected by DBUS interfaces.
Not tied to Linux desktop, also possible on MacOS and win32.
UI
|
Mission Control (== libkopete)
|
Connection Manager (== Protocol in Kopete speak) manages 1 or more accounts,
allocates communication channels on demand (KopeteMessageManagers)
The main channels cover lowest-common-denominator messaging, presence, contact
list management, privacy, contact details. To access richer services
supplied by a particular protocol, connection managers offer a getInterfaces
method returning paths to 'proprietary' functionality.
There may be >1 Connection Manager of course.
Galago is proposed as the presence layer but we did not go into much detail on
this (I think there are many open questions about the Galago architecture, is
it too complex, can we define useful subsets such as a reimpl of KIMIface or
an even more restricted presence system for an embedded device with fixed
components?).
ATM implementation is only a python based Jabber Connection Manager and one
for VoIP with testbed level frontends.
*) BasysKom presented their take, they and Stichting NL.net want to create a
standard way for apps to access VoIP and traditional telephony services,
which coincides well with Telepathy.
Questions they raised are: do the UI and Mission Control reside in the same
process, what's left to do on the spec, automatic generation of interfaces
(like dcopidl) and how to continue working together in future?
This took most of the meeting to present, afterwards we had a short
discussion, topics included missing/unclear stuff from the spec - doesn't
cover rich text messaging, some searching, async calling (all DBUS methods
can be called in sync or async mode which is nice). We also talked about
candidate toolkits - everyone has their own preference, Collabora would tend
to glib, BasysKom to Qt, on embedded systems small footprint is a concern,
and there could be problems with some zealots not accepting Qt. Since
proprietary protocols have relatively stable feature sets it would be
desirable to specify these in more detail than "query getInterfaces and go
from there" so that UIs aren't tied to a particular Connection Manager
implementation.
The usual mailing list, website, wiki, defect tracking was discussed and set
in motion.
So, my take, and reasons for being interested:
A year or 2 ago Lilachaze (Richard Smith), Duncan and I talked over separating
Kopete into distinct processes, to aid stability, performance and also to
allow access to IM without having to have a traditional contact list window
type UI visible. The results are on the KDE wiki at
http://wiki.kdenews.org/tiki-index.php?page=Kopete+Development+ContactListResource
We never got beyond talking about it due to lack of time, but we realised it
would be a lot of work. The Telepathy guys have done most of the design work
for us. We will have to redesign the RPC interface anyway with the move to
DBUS for KDE4.
I propose that for KDE4 we restructure Kopete as planned earlier, building on
the Telepathy framework to do this.
Benefits to Kopete IMO:
*) Stability, a crashing protocol can't take down the whole system.
*) Performance, Kopete is an event driven single threaded app, but events may
come from several network sockets or from the user or from the many timers we
use for UI eye candy</rant>, so it feels slow.
*) Cleaner architecture, a more loosely coupled design with well defined
interfaces is much easier to understand and the consequences of making
changes at one level will be easier to see at others. This makes Kopete a
more vital project, easier to attract developers from various areas, easier
to maintain.
*) Influence - Telepathy is not a finished design, we are the mature IM app
involved at an early stage so would be sharing our experience.
*) Broader user base - libkopete has not been used outside Kopete unlike
libgaim. A DBUS interface makes this possible at more levels, we could have
other desktops/OSs using our stable and secure network layers.
Benefits to KDE and rest of world
*) Easier to use Kopete's IM services and those of other apps in a uniform way
- access to a broader range of messaging services
*) Using Qt in real cross-desktop applications, as a core participant.
That's it, I'm going to bed, and I haven't forgotten about finishing the
AddContactDialog bits.
Will
_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
