Libomniconnect
This page details my SoC project for 2006.
Original application
Generic user-to-user connection interface for collaborative applications using telepathy
I believe a big leap forward for the Gnome desktop could be accomplished if collaborating and communicating with others is tightly integrated in as many aspects of the system as possible. For example it should be very easy to open a session in Gobby with another user, even if that user is not on the local LAN. For the local LAN we have Avahi for service discovery, but for connecting to remote users, no solutions exist. I would like to create such a solution, that will uniformly handle connecting to a remote user, as well as a remote user, known through an IM-network. My imaginative use case is as follows: Homer wants to collaborate on a document with Marge, who is online on a IM-network. He opens Gobby, chooses to start a session, chooses "Invite" and is given a list of persons he can invite from his contact list. He invites Marge to join. A little later Homer wants to bring Bart into the collaboration. Bart is on LAN with Homer, but does not use IM. Homer chooses "Invite" and inputs Barts IP, and Bart joins the session.
I would like to create a interface and specification for allowing programs like Gobby, gShrooms, VNC ("user applications"), to connect using one programming interface, regardless of whether the connection is a direct TCP-connection, or a connection established over an IM-network. This will enable developers of applications (primarily collaborative applications) to use a single API, and allow the connection to the other user to be handled by this API.
The interface/library will need to provide dialogs for starting a session, joining a session and inviting others to join a session. API-wise it should provide an interface exactly like a normal socket, for easy porting of existing applications.
My idea for the specification is to add a new channel type for generic P2P connections to telepathy, implemented in the Jabber connection manager as a "stream". Streams can then be initiated using JEP-0095 (http://www.jabber.org/jeps/jep-0095.html). It should be the responsibility of the user application to request a specific kind of stream. Mission control will need to be updated to handle and advertise these custom channel types, added by user applications. Regarding protocols other than Jabber, interoperability will probably be hard to implement, as e.g. MSN only supports a few hardcoded types of "streams", like exchanging drawings etc. It should however be included as a possibility in the design to handle these, if a user application advertises support for e.g. MSN drawings. I will not work with integration with avahi, but this is of course an obvious feature to integrate.
Deliverables
- A specification for how telepathy needs to be extended
- Extensions of Gabble to allow it to handle the new specification
- An implementation of a Glib library to easily integrate into user applications, providing means of getting available persons to connect to/invite and establish connections, workname: "libomniconnect"
- A GTK-based library providing standard dialog boxes for handling session starting, joining and inviting, building on libomniconnect. Workname: "libgomniconnect"
- Extension of obby to use libomniconnect and of gobby to use libgomniconnect
- By the deadline I expect the use case described above to be implemented.
Proposed schedule
- June: Doing exams + sketching specification. Getting telepathy set up and getting familiar with Gabble and Gobby codebase.
- 1. July: Development commences, specification done
- 10. July: JEP-95 Stream initiation and JEP-30 Service discovery implemented in Gabble
- 20. July: JEP-65 Socks5 Bytestreams implemented, first connection through new channel type
- 1. August: libomniconnect first draft, can connect through Gabble
- 10. August: libomniconnect implemented + obby extended to use it
- 15. August: libgomniconnect implemented + gobby extended to use it
- 21. August: Final deadline