DesktopIntegrationSIPIM

Differences between revisions 4 and 6 (spanning 2 versions)
⇤ ← Revision 4 as of 2005-09-23 16:46:13 →
Size: 4136
Editor: xdsl-84-44-157-28
Comment:
← Revision 6 as of 2005-09-23 18:56:05 → ⇥
Size: 5847
Editor: i-83-67-93-15
Comment: semi-rewrite
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
Existing free IM software connects to either a single network (such as Jabber) and implements as much of that network's functionality as possible, or provides plugin architecture to connect to various networks and attempts to implement as many of the features in common on those networks. In either case the result is a large base of code which tries to do a great number of different tasks from the same program, leading to complicated and confusing user interfaces, poorly maintained areas of code, and violates the general principle of 'do one thing and do it well'.
 Existing free IM software connects to either a single network (such as Jabber) and implements as much of that network's functionality as possible, or provides plugin architecture to connect to various networks and attempts to implement as many of the features in common on those networks. In either case the result is a large base of code which tries to do a great number of different tasks from the same program, leading to complicated and confusing user interfaces, poorly maintained areas of code, and violates the general principle of 'do one thing and do it well'. Furthermore, each monolithic program tends to export its own unique IPC interface for interacting with other programs, meaning that if integrating its functionality into other applications is desired, the work must be done for a specific application, restricting interoperability and the user's choice.
Line 25: Line 24:
Defining an extensible interface between backend server connections and to the user interfaces will allow seperate simpler programs to implement one part of the functionality, be it reliable connection to a Jabber or a SIP server, or present a single consistent user interface to the user for having an IM chat, making a voice call, or transferring a file. Todays popular desktop applications are e-mail clients, IM clients and VoIP phone software, and they each open their own connections to their own servers, and provide their own different UI to similar functionality like having a text conversation, having a voice call or transferring a file. The existing [http://www.galago-project.org/news/index.php Galago] project set out to define a library, server and D-Bus protocol to share presence and address book information between any application that deals with people, and is already gaining support in existing IM and e-mail client software (eg it provides plugins that allow you to see in Evolution or Beagle that your contact is online to talk to in Gaim). Extending this idea by defining an extensible interface between backend IM & VOIP server connections and the frontend UI programs will allow seperate simplified programs to implement one part of the overall IM & VOIP functionality, and increase the code shared between different client UIs. The standardised interface will allow the shared backend connections to be available to the best application for the task in hand - a phone application for making phone calls, an IM application for text chat, and a file manager for sending files.
Line 29: Line 28:
Todays most used desktop applications are eMail clients, InstantMessaging clients and VoIP Softphones, so it could be like this: 1. Ken installs Ubuntu and wants to be able to write an e-mail, chat with instant messages or his friend Barbie. He starts up his address book and adds Barbie's e-mail address, IM username, SIP ID or phone number (or maybe just a single Launchpad ID to do it all? :D), and it tells him that she is on-line and available for an IM chat or to recieve a VOIP call. Ken clicks on her name and his IM client starts for him to talk to her.
Line 31: Line 30:
1. Ken installs Ubuntu and wants to write an eMail, write an instant message or wants to phone his friend Barbie. So he starts up his eMail application and adds his friends eMail/IM-ID/SIP-ID/PhoneNumber to his addressbook.
The addressbook now tells him that his friend Barbie is Online, so he can instant message her, and the addressbook tells him as well, that she is able to receive VoIP phone calls. So Ken clicks on her ID and starts a voice chat with Barbie.		 2. Barbie is talking to her friend Kelly over IM and the buddy list shows that she is also available for a voice call. She clicks the icon and the phone application starts and sets up a call with Kelly.
Line 34: Line 32:
2. Ken knows someone in India, who has no bandwith for Voice Chats, but his buddy is able to do Instant Messaging e.g. via Jabber, so Ken adds his buddy to the Addressbook and it tells him, that his indian friend is online and available for a text chat. Ken klicks on his contact and he starts chatting.

3. Barbie, meanwhile, tries to reach her bank to apply for a new credit for her new Computer, which runs Ubuntu. She adds her contact at the bank to her addressbook and the Addressbook tells her, that her contact is not online, but she can write him an eMail. She clicks on the contact and start writing an eMail.
(If she ever got approved for the credit, we actually don't know)
 3. Ken is browsing his photographs in his file manager and finds a photograph of himself and Barbie on holiday in Spain. He right clicks and selects "Send To" and gets a list of all his contacts who are on-line and can recieve files. He chooses Kelly and the file transfer is initiated.
Line 42: Line 36:
We will work closely together with the IPCF Team (http://ipcf.freedesktop.org/wiki/) for the underlaying protocol.
You can see here (http://robot101.net/files/tmp/IPCF.png) the integration into already existing desktops. (The diagram is a bit outdate, but you should get the idea).		 We will work closely together with the [http://ipcf.freedesktop.org/wiki/ IPCF project] and use their D-Bus protocol for communicating between the back-end connection managers and client front-ends. The [http://robot101.net/files/tmp/IPCF.png overview] (slightly outdated) shows how different UI applications can share the same connection managers to achieve their respective tasks, and query a presence manager which is responsible for aggregating the availability and capabilities of your contacts via the various connections.
Line 45: Line 38:
The Presence Manager (galago -> http://www.galago-project.org/news/index.php) will be integrated into GNOME/KDE. This is the work of the IPCF Team. They will release a reference implementation for GNOME (*give a timeframe?*).
The Protocol Stacks (e.g. SIP, Video over IP, Jabber, ICQ, etc.) will be implemented as connection managers. The IPCF Team is focusing for the first release on Jabber and SIP.

The connection managers for the different protocol stacks are emitting signals for presence changes, which are picked up by galago.

The Presence Manager is providing a high level API for client developers, so it will be easy for every developer to integrate the functionality into their software (e.g. Evolution, Thunderbird, Kontact).
IM Clients like Gajim/Gaim/PSI/Kopete can easily be extented to support this system.
SIP /Video Over IP Clients (e.g. KPhone, Gnomemeeting, minisip) can be as well extended easily to provide support to the IPCF approach.		 Prototyping of a Jabber connection manager and a text mode client is currently being done in Python by the IPCF team and they will publish their protocol specification shortly, and by the end of the year they plan to have implemented native SIP and Jabber connection managers, a client library, and a feed of IPCF presence information into Galago. After the specification is published, seperate connection managers can be implemented to support other proprietary protocols such as MSN, Yahoo, AOL and ICQ, using the best-of-breed free software libraries available for connecting to these services (many of these are written in Python, so this work can be based off the prototype Jabber connection manager).
Line 55: Line 41:
IM and VOIP UIs can be written or existing applications modified to make use of the Python code or the native IPCF client library to make connections using the connection managers, carry out IM sessions and make and recieve VOIP calls (the IPCF project will use the Farsight library for this). Nautilus/Konqueror/gthumb/F-Spot can be patched to easily initiate file transfers with people in your address book.

The Galago presence manager has already gained some acceptance for sharing presence information between applications in the GNOME desktop and provides a high-level API for dealing with people and presence information. It can [http://pvanhoof.be/blog/index.php/2005/06/20/39-galago-and-other-important-desktop-integration-compontents#c45 easily be integrated] with its equivalent KIMProxy functionality in KDE, or a seperate IPCF feed can export the same information over KIMProxy.

Desktop Integration of SIP/IM in the (K)Ubuntu Desktop

Status

Introduction

Existing free IM software connects to either a single network (such as Jabber) and implements as much of that network's functionality as possible, or provides plugin architecture to connect to various networks and attempts to implement as many of the features in common on those networks. In either case the result is a large base of code which tries to do a great number of different tasks from the same program, leading to complicated and confusing user interfaces, poorly maintained areas of code, and violates the general principle of 'do one thing and do it well'. Furthermore, each monolithic program tends to export its own unique IPC interface for interacting with other programs, meaning that if integrating its functionality into other applications is desired, the work must be done for a specific application, restricting interoperability and the user's choice.

Rationale

Todays popular desktop applications are e-mail clients, IM clients and VoIP phone software, and they each open their own connections to their own servers, and provide their own different UI to similar functionality like having a text conversation, having a voice call or transferring a file. The existing [http://www.galago-project.org/news/index.php Galago] project set out to define a library, server and D-Bus protocol to share presence and address book information between any application that deals with people, and is already gaining support in existing IM and e-mail client software (eg it provides plugins that allow you to see in Evolution or Beagle that your contact is online to talk to in Gaim). Extending this idea by defining an extensible interface between backend IM & VOIP server connections and the frontend UI programs will allow seperate simplified programs to implement one part of the overall IM & VOIP functionality, and increase the code shared between different client UIs. The standardised interface will allow the shared backend connections to be available to the best application for the task in hand - a phone application for making phone calls, an IM application for text chat, and a file manager for sending files.

Scope and Use Cases

1. Ken installs Ubuntu and wants to be able to write an e-mail, chat with instant messages or his friend Barbie. He starts up his address book and adds Barbie's e-mail address, IM username, SIP ID or phone number (or maybe just a single Launchpad ID to do it all? :D), and it tells him that she is on-line and available for an IM chat or to recieve a VOIP call. Ken clicks on her name and his IM client starts for him to talk to her.

2. Barbie is talking to her friend Kelly over IM and the buddy list shows that she is also available for a voice call. She clicks the icon and the phone application starts and sets up a call with Kelly.

3. Ken is browsing his photographs in his file manager and finds a photograph of himself and Barbie on holiday in Spain. He right clicks and selects "Send To" and gets a list of all his contacts who are on-line and can recieve files. He chooses Kelly and the file transfer is initiated.

Implementation Plan

We will work closely together with the [http://ipcf.freedesktop.org/wiki/ IPCF project] and use their D-Bus protocol for communicating between the back-end connection managers and client front-ends. The [http://robot101.net/files/tmp/IPCF.png overview] (slightly outdated) shows how different UI applications can share the same connection managers to achieve their respective tasks, and query a presence manager which is responsible for aggregating the availability and capabilities of your contacts via the various connections.

Prototyping of a Jabber connection manager and a text mode client is currently being done in Python by the IPCF team and they will publish their protocol specification shortly, and by the end of the year they plan to have implemented native SIP and Jabber connection managers, a client library, and a feed of IPCF presence information into Galago. After the specification is published, seperate connection managers can be implemented to support other proprietary protocols such as MSN, Yahoo, AOL and ICQ, using the best-of-breed free software libraries available for connecting to these services (many of these are written in Python, so this work can be based off the prototype Jabber connection manager).

IM and VOIP UIs can be written or existing applications modified to make use of the Python code or the native IPCF client library to make connections using the connection managers, carry out IM sessions and make and recieve VOIP calls (the IPCF project will use the Farsight library for this). Nautilus/Konqueror/gthumb/F-Spot can be patched to easily initiate file transfers with people in your address book.

The Galago presence manager has already gained some acceptance for sharing presence information between applications in the GNOME desktop and provides a high-level API for dealing with people and presence information. It can [http://pvanhoof.be/blog/index.php/2005/06/20/39-galago-and-other-important-desktop-integration-compontents#c45 easily be integrated] with its equivalent KIMProxy functionality in KDE, or a seperate IPCF feed can export the same information over KIMProxy.

[CategoryUbz] [CategoryMOTUIM] [CategoryMOTU]

MOTU/Teams/IM/DesktopIntegrationSIPIM (last edited 2008-08-06 16:41:24 by localhost)