Telepathy IM/VOIP Framework

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Telepathy IM/VOIP Framework

Robert McQueen-2
Hi folks,

I'm Rob McQueen, one of the founders of an open source consultancy in
Cambridge, UK called Collabora Ltd (5 of us in total, 3 in Cambridge).
For the past year or so we've been working on a D-Bus based abstraction
layer for IM and VOIP services called Telepathy. I had a chat with Chris
Blizzard at GUADEC about our work and it seemed that there was
potentially a really good match between what OLPC needs from messaging
and presence, and what the Telepathy project has done and is looking to do.

Telepathy is fundamentally a D-Bus API for talking to IM/VOIP servers.
Your connections are established by backend processes called connection
managers, which implement the API and present an abstraction which is
the same whatever the underlying protocol. UI components are implemented
as seperate programs using this D-Bus API, gaining immediate benefits
like isolation from the protocol, language (and even license) of the
backend code, as well as the ability to share the same connections
between different processes, or not run parts of UI code when no
communication activity is taking place.

The Telepathy framework forms the basis of the Google Talk and Jabber
implementation on the 2006 OS release on the Nokia 770. This means we
already have a mature Jabber/XMPP backend component, and also a
GStreamer-based streaming engine for establishing GTalk voice calls,
both implemented in C with glib.

We're looking now at integration of these components into the GNOME
desktop, integrating presence into address book components, file
transfers into Nautilus, porting Gossip to speak Telepathy (and hence
any protocol you can think of) etc. People in the community are working
on other backends including IRC, SIP, MSN and Oscar (AOL/ICQ/iChat), and
we're working on adding video calls, file transfers, avatars and such
like to the spec and our XMPP backend.

Chris showed me some of the ideas about messaging and presence which the
OLPC project has been working on, with the multicast protocol,
sketching, avatars, and activities which people can collaborate on,
which all looks cool, and has a really good overlap with things we've
been planning to work on.

The XMPP protocol already defines a mechanism for link-local messaging
(JEP-174, http://www.jabber.org/jeps/jep-0174.html), using mDNS for
advertising presence and your buddy icons, and sending point to point
messages by bringing up direct peer to peer connections. We've been keen
to implement this in our XMPP backend, and it's easy to conceive of some
extensions to XMPP (that's what the X is for :D) which would allow the
activities to be supported.

As well as this the Jabber community is working on standardising
Jabber-based whiteboard/sketching based on Jabber, which we'd love to
see in Telepathy as well. One thing we'd need to look into would be
working out a way of forming ad-hoc multi-user chats using multicast,
but it's something which we could put forward as a JEP once we'd worked
it out, and gain interoperability with desktop or other mobile (770 and
friends :D) Telepathy implementations.

Pondering scalability, on larger scale deployments, adding an XMPP
server would allow the same stack to be used with a minimum amount of
disruption. You could even leverage Telepathy's protocol support to
implement a backend that's used in ad-hoc configurations that wasn't
necessarily XMPP-based, but use XMPP when a server was available.

This e-mail turned into a bit of a brain dump, but hopefully we can
discuss some of these ideas. For more information on Telepathy, see
http://telepathy.freedesktop.org - I'm going to read your D-Bus
Presence/Activity API now too. :)

Regards,
Rob
--
Robert McQueen
Director, Collabora Ltd.
Reply | Threaded
Open this post in threaded view
|

Telepathy IM/VOIP Framework

Marco Pesenti Gritti
Robert McQueen wrote:

> Hi folks,
>
> I'm Rob McQueen, one of the founders of an open source consultancy in
> Cambridge, UK called Collabora Ltd (5 of us in total, 3 in Cambridge).
> For the past year or so we've been working on a D-Bus based abstraction
> layer for IM and VOIP services called Telepathy. I had a chat with Chris
> Blizzard at GUADEC about our work and it seemed that there was
> potentially a really good match between what OLPC needs from messaging
> and presence, and what the Telepathy project has done and is looking to do.
>
> Telepathy is fundamentally a D-Bus API for talking to IM/VOIP servers.
> Your connections are established by backend processes called connection
> managers, which implement the API and present an abstraction which is
> the same whatever the underlying protocol. UI components are implemented
> as seperate programs using this D-Bus API, gaining immediate benefits
> like isolation from the protocol, language (and even license) of the
> backend code, as well as the ability to share the same connections
> between different processes, or not run parts of UI code when no
> communication activity is taking place.
>
> The Telepathy framework forms the basis of the Google Talk and Jabber
> implementation on the 2006 OS release on the Nokia 770. This means we
> already have a mature Jabber/XMPP backend component, and also a
> GStreamer-based streaming engine for establishing GTalk voice calls,
> both implemented in C with glib.
>
> We're looking now at integration of these components into the GNOME
> desktop, integrating presence into address book components, file
> transfers into Nautilus, porting Gossip to speak Telepathy (and hence
> any protocol you can think of) etc. People in the community are working
> on other backends including IRC, SIP, MSN and Oscar (AOL/ICQ/iChat), and
> we're working on adding video calls, file transfers, avatars and such
> like to the spec and our XMPP backend.
>
> Chris showed me some of the ideas about messaging and presence which the
> OLPC project has been working on, with the multicast protocol,
> sketching, avatars, and activities which people can collaborate on,
> which all looks cool, and has a really good overlap with things we've
> been planning to work on.
>
> The XMPP protocol already defines a mechanism for link-local messaging
> (JEP-174, http://www.jabber.org/jeps/jep-0174.html), using mDNS for
> advertising presence and your buddy icons, and sending point to point
> messages by bringing up direct peer to peer connections. We've been keen
> to implement this in our XMPP backend, and it's easy to conceive of some
> extensions to XMPP (that's what the X is for :D) which would allow the
> activities to be supported.
>
> As well as this the Jabber community is working on standardising
> Jabber-based whiteboard/sketching based on Jabber, which we'd love to
> see in Telepathy as well. One thing we'd need to look into would be
> working out a way of forming ad-hoc multi-user chats using multicast,
> but it's something which we could put forward as a JEP once we'd worked
> it out, and gain interoperability with desktop or other mobile (770 and
> friends :D) Telepathy implementations.
>
> Pondering scalability, on larger scale deployments, adding an XMPP
> server would allow the same stack to be used with a minimum amount of
> disruption. You could even leverage Telepathy's protocol support to
> implement a backend that's used in ad-hoc configurations that wasn't
> necessarily XMPP-based, but use XMPP when a server was available.
>  

Hi Robert,

Dan Williams has been looking in telepathy/galago. Also he has been
focusing on the presence/communication part of sugar. He is in vacation
right now but I'm sure he will answer in a more complete way than I can
do when he is back.

Anyway, here is some (not so informed) brain dumping... There are a few
things in telepathy that I think could be beneficial to sugar:

- The streaming engine. Supporting voip is in the plans but we have no
code for it yet.
- XMMP communication protocol support. We have been to move to it at
some point.
- User identification.
- Server support for scalability.
- Code reuse.

Things I don't think will matter that much to us:

- Support for multiple chat protocols.

Problems to solve:

- There are two basic use cases for the network that we need to keep in
consideration (a simplification admittedly):

1 In school use, lots of users, server available.
2 Home use. Small groups of kids, no server available.

As far as I can tell Telepathy does not cover 2, That's a major problem.
Is it solvable?

- Presence in Sugar is more than buddies presence. Activities are
present. Services and buddies are present inside the activity. Buddies
owns services. This somewhat map to the concept of group in instant
messaging (and I suppose in telepathy) but it's not quite the same.
Dan API writeup can give you a good idea of our requirements:
http://wiki.laptop.org/go/Presence_Service_DBus_API

- Sugar communication API needs to be capable of more than IM and voice.
It should be easy to implement a shared whiteboard or cooperative text
editing on the top of it. Hopefully this is already covered.

- Sugar presence API need to be very simple to use and tidied to the
framework. We don't want to expose D-Bus to the poor kids :) The
solution to this might just be to implement our presence API using
telepathy rather than exposing telepathy API directly.

- How does user identification work without a server? (This is totally
an open issue for sugar too)

Finally, Ivan and his group needs to be involved in this. (Hopefully
some of them are subscribed to this list). I don't know that much about
their plans but a few weeks ago I think one of the main points was to
have presence/communication API usable from web browser javascript,
through a local web server.

Web Browser  -> Web Server -> Telepathy ?

Anyway, great to see you interested. Let's keep talking!

Marco