[Telepathy] Saying hi

[Stefan Eilers]

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

Hi Raphael!

Am Montag, 24. April 2006 00:51 schrieb Raphael Slinckx:

> Since we are starting to discuss the Mission control subject i might
> just stop lurking and say hello too !

:D

>
> I recently started working for collabora on a gtk/gnome UI for telepathy
> codenamed 'cohoba'. The aim is to provide a completely integrated way to
> talk to people in the gnome desktop, and not just be a gaim/psi or
> whatever common interface we have these days (not that it's bad, but
> being innovative is a good advantage for telepathy acceptance)

Our motivation is exactly the same.

> The code can be found in collabora darcs repos under telepathy-gnome
> module.

Cool, we will look at it.
>
> Right now it support only text conversations and a merged contactlist
> for different accounts, as well as rough support for tagging contacts
> and creating groups of contacts. I work on it as soon as i get some free
> time but these days, university work is overwhelming.

Right. The important think is to identify the aspects which are really related 
to GNOME, KDE, .., whatever and what is general. Then, we need an interface 
between them to be able to exchange them transparently.

Just some brainstorming:

Gathering information from all accounts, is a typical general job for a 
central component, shared between us.

This leads to typical use cases:
Any application which wants to show any presence information will ask:

Who is out there? And will get all the people (optionally in a grouped manner) 
from mission control.
Then, it may ask for a communication connection to the selected contact. It is 
the job for mission control to find the right connection manager, connect to 
it and start the appropriate client for this communication..

To summarize: I see the following tasks for the desktop interface 
specification:

Client View:
1. Client wants to get information (presence, network states,..)
2. Client wants to publish information (local user presence,...)
3. Client wants connection to anyone..

Telepathy-View:
1. Mission Control wants to notify about network/presence changes 
2. Mission Control wants to notify about incoming requests
3. Mission Control has to open the right desktop client for notifications, 
activated connections, ..

Additionally, we need a central configuration which defines what mission 
control should do and which clients do exist for the various tasks. It has to 
be independently to the desktop itself. 
Starting of clients is a job for D-BUS or any special desktop service on top 
of D-BUS.. 

Maybe I don't see a lot of important aspects and the list above will not 
contain everything, but I'm sure this is the right direction to think.

> On my side i would love starting implementing whatever mission control
> interface results from the work for gnome, maybe reusing common code if
> it's useful (if the mission control code is non-trivial), but i doubt it
> will require lot of code sharing since the tasks are basic for the most
> part.

Right. We have to share the code for mission control (I'm very sure it will  
not be trivial, if you want real innoviation) and the interface to the 
desktop (the DBUS specification for it). The rest will be different..
Thus, we have to discuss the programming language for mc. I'm sure you will 
prefer python. We think more towards embedded systems, where every additional 
library and runtime environment is a problem. Due to this fact, we think 
about plain C. But maybe we should have various versions which may be more 
advanced and written in a higher language than C and an embedded release 
which just has some basic functionality.. Time will show.

>
> This also include integration of accounts setup for example in
> evolution-data-server or gnome-keyring, so the user can setup his
> accounts in a capplet once for all and then all telepathy UI will 'just
> work'.

This is the part which is different. Thus, we should store the account and 
contact information on the desktop. But if mission control need information, 
it has to be able to get it in a transparent way. I'm not sure how.. Maybe 
using a desktop service which answers to information requests from mission 
control.

>
> What i have in cohoba isn't a proper mission control. I have an
> interface for setting up accounts and starting/stopping connections, as
> well as code for handling incoming text and contact list channels.

Ok, but this is the correct start for mc. 

>
> I don't really like the way it is because all is too coupled together
> which is what telepathy want to avoid, the user interface would just
> have to ask mission control "give me all the connections the user has
> setup (and if necessary create the connections)".

Right. 

>
> The mission control should also have access to account credentials to be
> able to log in, in whatever way the underlying desktop works (gconf in
> gnome for example)

Right. This looks as if we need a desktop service which ansers to mc if it 
needs such information.

>
> And finally about the incoming channel handling, i'm not sure how this
> can be achieved without being too intrusive. Maybe as we discussed the
> other, some field in .desktop files can be used to indicate that a
> program can handle dbus interface x and y, the mission control would
> then scan the available programs and start the correct program to handle
> channel types.

I thought about a configuration structure, used by mc which stores this 
information for it (as XML file). And a desktop service, which fills in the 
information needed. 
Aditionally a user configuration tool should help to define priorities. For 
instance, if a VOIP-Call is incoming, I would prefere tool A instead of tool 
B.. 
And more important: If we have multiple possibilities (for instance a  SIP 
connection manager in software and a telephony hardware connection manager), 
the user has to give priorities who is used first.
>
> I think Robert was willing to send an email to the list with a first
> mision control interface draft "real soon now"..

Great. As the collabora guys were first with telepathy, they should have the 
honor to speak first.. :)
The most important think is, that we are able to commit ourselve to a sharable 
telepathy framework. The rest is our private obsession, whether we use KDE or 
Gnome or FVWM.. ;)
But I'm quite confident that this will be no problem, as we all have the same 
goal and the same basic infrastructure in mind.

Bye, Stefan
- -- 
Stefan Eilers
Project Manager

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-962 | Fax: -736 | Mobile: +49 170 4213459 |
Jabber: eilers at jabber.org
stefan.eilers at basyskom.de | www.basyskom.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFETJpEgHBfg4VrVxARAgVsAJ0X2oDVTokn6EktcjCKUPAAlS1TnACfYi0q
/KDniEf7cF/1aVueamXmp80=
=WhwC
-----END PGP SIGNATURE-----