[Telepathy] suppot for serverless IM

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Oct 2007 at 20:52:38 +0200, Michael Schmidt wrote:
> Hi the Koffice list told me, that telepathy is integrating all IM
> protocols, would it be possibe to integrate as well this serverlesss?
> Thanks Mike

About the Qt GUI:

The way to integrate this (or any) GUI with Telepathy would be to make
it use the Telepathy D-Bus API to communicate with connection managers,
either directly or with the help of Nokia's Mission Control (NMC) or
basysKom's Decibel. This would enable it to support any protocol for
which we have a connection manager. Currently that's:

* XMPP/Jabber (Gabble) (interoperates with Google Talk and others)
* Link-local XMPP, XEP-0174 (Salut) (interoperates with iChat, Pidgin etc.)
* SIP (telepathy-sofiasip)
* MSN (Butterfly)
* Everything Pidgin supports, including MSN and AOL (Haze, which uses libpurple)

but anything added by a core or third-party connection manager can also
be supported.

If KOffice is going to include instant messaging functionality, I think
it makes a great deal of sense to use Telepathy for it.

I understand there have been some efforts to port Kopete to be a
Telepathy front-end - you may be able to use code or libraries from that.

Ideally, Telepathy integration into KDE would follow the same approach
as we use with Empathy in GNOME:

Empathy mainly consists of a couple of libraries (libempathy is a non-GUI
convenience library wrapping Telepathy and NMC using GLib; libempathy-gtk is
a set of GUI widgets using gtk and libempathy). /usr/bin/empathy itself is
just a trivial wrapper around libempathy-gtk. This makes it easy to integrate
Empathy widgets into other gtk applications. By replacing GLib/gtk
references with Qt/KDE ones throughout that description, you could get some
sort of libkdetelepathy that Kopete, KOffice and any other KDE app could
use to share IM connections.

- ------------

About the Retroshare network protocol (bear in mind that today was the
first time I'd heard of this protocol!):

Because of the "network effect" intrinsic to IM protocols, I don't
believe that inventing or promoting a new protocol is a good idea. You can't
use a protocol that your friends aren't also on (unless you can somehow
convince them to use it), and if there's only one implementation of that
protocol, that's a bad sign.

If you want to promote a protocol or protocols, I'd recommend XMPP
(Jabber, Google Talk) for conventional server-based communication across
the Internet, and link-local XMPP (XEP-0174, aka "Bonjour") for local
networks with no infrastructure or configuration. Both protocols are
sanely designed and fully extensible.

Elaborating on that a bit:

We already support a serverless link-local protocol, link-local XMPP
(XEP-0174), which interoperates with iChat and Pidgin (among others).
It's the same protocol that Apple refer to as Bonjour. Our implementation
of this protocol, Salut, extends it to feature multicast chat rooms and
arbitrary collaborative applications over Tubes, is under active development,
and is a core component on the One Laptop Per Child.

If retroshare is considered useful, integrating it with Telepathy would
require writing a Connection Manager (a daemon similar to Salut) that
implements the retroshare protocol instead of XEP-0174. Once this was
done, any Telepathy user interface (e.g. Empathy) should be able to
add and use Retroshare accounts.

I'm not really convinced that having more than one link-local protocol
makes sense, particularly when XEP-0174 is extensible - I think
we should be encouraging use of XEP-0174 rather than "fragmenting the
market" - but anyone is welcome to write a Telepathy connection manager;
the D-Bus spec is available from <http://telepathy.freedesktop.org/spec.html>
and we have Python and C/GLib libraries that can help you implement a CM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFHD1qSWSc8zVUw7HYRAr1PAJ9jRPGKq/J+GSSG4h4cKD5s4+x3SQCg7uJK
n+P59azgPkiMHjlXx6yyc9U=
=bQ73
-----END PGP SIGNATURE-----