[Telepathy] list fixed

[Stefan Eilers]

Am Sonntag, 19. März 2006 02:04 schrieb Robert McQueen:
> Sorry for the silly message, but if you get this then the renaming of
> the list from IPCF to Telepathy has been succesfully repaired, so now we
> can go on and discuss what the next steps are to move forward the
> Telepathy community.

Cool.. :)

Maybe we should continue the discussion, which started on the meeting at 
FOSDEM:

IMHO we need to clearify some important things which belongs to the 
Mission-Control stuff:

I think we agree that it is important to design an architecture where the 
clients will talk to mission-control instead with the connection managers 
directly. This would provide the opportunity to reduce complexity in the 
clients and to solve various problems (ressource problems, signalling, ..) in 
a central manner.

The question is, which services have to be integrated as an general part of 
the Telepathy infrastructure and what has to be desktop specific and how to 
interact between them. 
The general part should contain everything which is needed to help 
applications to solve their requests as easy as possible in a platform 
independent way, but it should use services which are expected to be 
available on every desktop, to solve its job.
For instance: It does not make sense to store addresses or other contact 
information by Telepathy. Thus, we have to discuss an interface which allows 
MissionControl to request such information from an desktop system if it needs 
it.

To be more concrete, we may start with the following questions:

1. What services expects a desktop application from such an infrastructure? 
For instance, an application should just have to say: "I want to have a 
textbased communication to X". Mission control should decide by itself which 
protocol and connection manager should be used to solve this. 
Or: "Give me all persons which are currently online"..
This would allow developers to write clients in very a simple way.
Does anybody (especially the developers of chat applications) have additional 
ideas?

2. Incoming connects: How to inform/start client applications? We should use 
as much of the D-BUS way to doing this, as it is the common part between all 
desktops. If we need desktop specific solutions to start applications, they 
should be put on top of the D-BUS system. Thus, mission control should not be 
aware of any desktop specific stuff to be as portable as possible.. Does any 
KDE/Gnome specialists have any ideas here what currently exists and how to 
handle this? What do we need to realize such an starter or what is already 
available?

3. ?? Any additional questions?
 
We should gather the ideas of this discussion to design a protocol/interface 
specification out of it.

What do you think?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20060321/f98ae12c/attachment.pgp