Telepathy Mission Control for the GNOME Desktop

Synopsis
--------
Telepathy lacks an appropriate "Mission Control" to be completely usable as a
distributed desktop component. Mission Control is the telepathy jargon for defining the
piece of software dictating the policy of instant messaging (and audio/video)
on the desktop, as well as keeping track of connections.

Project Details
---------------

The mission Control must answer these questions:
* What telepathy connections are open?
* Sign on/off to all accounts/account x for me
* Get me a text/voice/video channel with person X

It must also know where to retreive all setup accounts settings (ie. gnome-keyring, gconf, file,..)

And finally it must handle incoming requests (incoming text channel, video channel,..) and
handle conflicts (receiving two phone calls, using the camera with one active conversation, and a new one is incoming)

To setup the mission control the preferred applications capplet can be modified
to indicate preferred chat/video/voice channel handlers that will be activated by the mission control.

This leads to modify dbus' .service files to include a mechanism to associate services with
an interface they provide, and linking to .desktop files, so one could parse the services and get
a meaningful description of programs capable of handling dbus interface x. For example:
liferea.service:
  Service=RssReader.liferea
  Executable=/usr/bin/liferea
  Desktop=/usr/share/applications/liferea.desktop
  Interfaces=RssReader

This would also benefit epiphany for example where we can't use dbus-activation because we don't know
which rss reader is present on the system.

Deliverables
------------
- The DBUS API of the mission control
- The mission control implementation for the gnome desktop, including
  - The dbus-activated daemon
  - A capplet to setup accounts (possibly in about-me)
  - A capplet to choose preferred channel handlers (possibly in preferred application capplet)
- A new library or a modification of libgnomedesktop or libdbus-glib, that allows to
  read dbus .service files, create a list of all applications capable of handling dbus interface X.

Schedule
--------
Normally the three month allowed by the google summer of code project should be enough
to analyze, develop and implement this project.

I'll be able to work on this project during the two month of the summer starting the 1st july
(right after the Guadec). I won't be able to do much except self-documentation and
studying the existing code, because of the exams taking place from 6th june to 24th june.

- begin-15 july, the dbus API and a basic prototype.
- 31 july, a robust implementation and the .service modification is finished
- 1 august to EOSoC, implementation of the various capplets

If time allows, i'll also continue to update the Cohoba client (see bio) to make
use of this mission control so a complete product can be published at
the end of the work.

Who Am I?
---------
I'm an engineering student in computer science at the UCL in Belgium
(Université Catholique de Louvain-la-Neuve), finishing my fourth year (5 years in total).

I'm a GNOME contributor since a year, starting with little patches and extensions
for applications such as epiphany, beagle, rhythmbox, then i wrote the Deskbar Applet
that I also maintain as part of the GNOME desktop.

I got involved in the telepathy community quite recently, and started writing a client
for it, codenamed Cohoba which will be further developped as time allows between
two courses.

I know and program in java, C# and python since 2 years, and have a good understanding
of the foundation libraries of the desktop (gtk, gnome*, glib).

I'm submitting this proposal in case I wouldn't be selected as mentor for GNOME this summer,
I can then do student work, as the conflict would be resolved.