TelepathyContactIntegration

Specification

Summary

This specification tackles the problem of (re)presenting contacts in a consistent way to the user. Since we now have a single source of presence feed, we can do galago's current job easier and update the ideas of project soylent (see bottom of page for references).

Rationale

Existing infrastructure:

  • Galago: A Daemon that has feeds for each presence-feeding IM client and feeds for adressbooks such as evolution-data-server (e-d-s). It reads and merge the incoming datas, and store them in-memory. Clients can then ask galago for existing people on the system, and can also query with arbitrary key/value people for attributes (stored by the galago daemon). The problem is the duplication of the data, and the inconsistent state between galago and e-d-s information (as outlined by Carlos on the 770).
  • Evolution-data-server: The canonical gnome storage for adressbook-type data. It stores on disk the information, and provides an IPC way to query this data (through corba or dbus on a branch by opened-hand). It is now mainly used to store a vcard about the contacts. Presumably there is an equivalent for KDE of this. We would like to store presence transient information in the same place as static info, since it's basically a property of the contact, be it persistent or transient. This would also alleviate the synchronization issue.

The way it works now, is that an application talks to e-d-s to retreive the vcard of a contact, then talks to galago to ask for presence, which in turn talk to e-d-s again and do the merging, storing a duplicate information, and creating a cycle that need to be arbitred by a syncing program (eds-sync on the 770).

Use cases

  • Raphael wants to have an audio chat with one of his buddies. He selects in a drop down list the contact he wants to talk to. The list shows only those contact that can actually have audio calls and that are online at that moment.
  • Simon wants to see at a glance who's online and what are the means of communication so he can kill some time off by talking to someone.

Design

A proxy software will centralize all requests and expose a unified, common interface to the external applications/libraries. This software will not store anything, just merge the data from the different sources and return a coherent view of the available data.

______________DBUS_______________
     |         |          |
[Presence] [VCard] [Capability]
          \    |   /
           [People]
          /    |   \
[Telepathy] [e-d-s] [kadressbook]

Presence, VCard, Capability are interfaces exposed by the "people" proxy over dbus. The API for these interface can be inspired by the Telepathy API, or *be* the Telepathy API (ie return data, or return references to telepathy/e-d-s pointers).

The proxy itself is connected to telepathy, e-d-s, kadressbook and more via dbus to get the data.

An example of query is "Give me all the available people with audio capability". The proxy receives the query, gathers all contacts in e-d-s that have an online handle, then asks telepathy for the presence and capabilities of these handles and finally returns to the original applications the filtered and merged request. The application has now a list of people (containing maybe several accounts) that can be talked to in addition to the vcards of these persons so that an useful UI can be constructed.

In the long run, the software proxy can be removed, and the dbus interfaces can be directly implemented by the e-d-s itself, if e-d-s learns to talk Galago.

Implementation

Existing softwares already exist that do part of the job, or ideas that have never been really implemented:

Carlos said he was going to bring the news back home, we will be trying to assemble a little team, including the soylent and galago contributors to try to get this project up to speed. There is nothing concrete now.

[JerryHaltom] It's not possible to merge in a central daemon without having all available information in that central daemon. This is what Nokia is trying to avoid, so lets try to work around it. Invision a Contact DBUS interface. The interface defines a bunch of data fields which are based initially on the information required in VCard. Each Contact object is locatable on the BUS through some means... either through a direct object or through a proxy and a handle. Either way, there is no central daemon. Each application hosts and exposes it's own implementaiton of the Contact interface. An interface is provided to SEARCH each's applications exposed Contacts on arbitrary datapoints. An application can easily enumerate all ContactProvider interfaces on the BUS and issue a query for a specific e-mail address or other data field to each. Results get returned. In addition to these data fields, each exposed Contact contains zero or more references to OTHER Contact instances on the BUS, either from the same application, or others. This allows applications to relate their Contacts to other Contacts from other applications. As each application exposes more Contacts, it queries other applications on the bus to search for matching data points. Matching data points get hooked up between applications. This results in sort of a cloud network of Contact instances. This can be provided by a library in each application. This allows an application to easily query for Contacts, match them with it's own, and display a meaningful relation to the user.


CategoryTelepathy
CategorySpec

TelepathyContactIntegration (last edited 2008-08-06 16:21:40 by localhost)