Google Summer of Code

Enhancement to peer-to-peer DBus for Telepathy DBus Tubes

Puneet Goyal

Short description: Telepathy is a modular framework for real-time communications that handles voice, video, text, file transfer, and so on. It makes extensive use of the D-Bus messaging bus and a modular design. When an application connects to a peer to peer dbus tube, it must know what exactly to look for. Even When it registers for another object, the other side of the tube must know about it. So the ideas is to create a class that could ease the object to register and unregister on the DBus Tubes, and to provide you with an interface similar to the one as a DBus Server.

Name: Puneet Goyal

Email Address: puneetgoyal08@gmail.com

Freenode IRC Nick: puneetgoyal

IM Service and Username: xmpp:gmail.com/Home, puneetgoyal08

Location: Bathinda, Punjab, India UTC+5.30 hrs

Proposal Title: Enhancement to peer-to-peer DBus for Telepathy DBus Tubes

Motivation for Proposal/ Goal:

D-Bus Tubes allow you to share a private DBus between two or more clients, proxied over Telepathy.Telepathy is a flexible, modular communications framework that enables real-time communication via pluggable protocol backends. Telepathy is a communications service that can be accessed by many applications ("clients") simultaneously.D-Bus is a message bus system, a simple way for applications to talk to one another.

When an application connects to a peer to peer dbus tube, it is difficult to know if an object is registered or unregistered. Even when it registers for another object, the other side of the tube must know about it. So the ideas is to create a class that could ease the object to register and unregister on the DBus Tubes and access the information about it.It would even let us create and share as many objects as we need, for e.g, we may want to run a no. of kwhiteboard applications and share them with other peers.

This might even be possible using introspect, but it is not a good way to implement it because there are no signals on the introspect interface, so it won’t be possible to know if other the remote side has registered some new object.Also,different channels and connection objects may offer different interfaces to each other, depending on the capabilities of the channel or connection, but that most of the implementations of D-Bus introspection assume that all objects of the same class will have the same interfaces.


Implementation Details:
  1. Create a class to use directly from the application to send or receive signals to register/unregister themselves to/from the dbus. Methods will be declared to receive the signals ,access to the methods of that object.
    1. Implement org.freedesktop.DBus.Peer Interface and Adapter:Design a minimal interface for checking whether the other end is reachable and if so, what machine hosts the object.
      1. Design a method to diagnose whether an object is reachable.
      2. Get the Machine UUID(Universal Unique Identifier) of the machine hosting the object..
    2. Implement org.freedesktop.DBus.ObjectManager Interface and Adapter: Implement the org.freedesktop.DBus.ObjectManager Interface for the server side with the following methods
      1. get_service: Retrieves a handle to the remote service on which the object is attached
      2. get_object_path: Retrieves the unique path identifier for this object within the service
      3. connect_to_signal: connects a callback signal emitted by the object
      4. disconnect_from_signal: disconnect from a signal emitted by the object
    3. Implement methods to connect to a org.freedesktop.DBus.ObjectManager and access its methods and signals.
  2. Implement Error control module
    1. new_error method: Creates a new error object whose name is given by the name parameter, and long descriptive text is provided by the message parameter. The name parameter has certain formatting rules which must be adhered to. It must only contain the letters ‘a’-’Z’, ‘0’-’0’, ‘-’, ‘_’ and ‘.’. There must be at least two components separated by a ‘.’, For example a valid name is 'org.freedesktop.DBus.UnknownFormat’.
    2. error_name method: Returns the dbus error name associated with the object
    3. error_message method: Returns the descriptive error message associated with the error condition.
  3. Create methods which emits local signals when the remote part registers/unregisters an object.
  4. Create methods to know which objects are currently registered.
  5. The real application will connect to the dbus using connectToPeer method.
  6. Use the Object of this class to connect to the dbus tubes in kwhiteboard and try creating as many objects as we need and share it with other peers.
  7. Create module for multiuser support
    1. When a new user connects to a bus, you will need to know which other users are connected and what do they export.
    2. Create a method to check which all connections are made on the DBus.
    3. Method needs to be made which will reply to that signal, giving the info about the objects they export.

Tentative Timeline(in weekly intervals until 2 weeks after the end of GsoC):

Phase-I(Study, porting Kwhiteboard)
  1. 23rd April - 2nd May: Study the peer to peer dbus codebase. Discuss the strategy with my mentor
  2. 2nd May - 1st June: Port the Kwhiteboard to the new API

Kwhiteboard is a shared whiteboard application built with telepathy. It allows you to run a shared whiteboard session with Instant Messaging Contacts.

Phase-II (Coding)
  1. 1st June - 7th June: Implement the org.freedesktop.DBus.Peer Interface and Adapter
  2. 7th June - 14th June:Implement the org.freedesktop.DBus.ObjectManager Interface and Adapter
  3. 14th June - 21st June: Implement methods to connect to a remote org.freedesktop.DBus.ObjectManager interface and use its methods and signals
  4. 21st June - 28th June:Implement the Error Control module.
  5. 28th June - 5th July: Create methods to emit local Signals when the remote part register/unregisters an object.
  6. 5th July - 12th July: Create methods to know which objects are currently registered to the DBus
  7. 12th July - 19th July:Use the object of this class to connect to the DBus Tubes in Kwhiteboard and register as many objects as needed to connect to the DBus Tubes.
  8. 19th July - 26th July:Create method to check which all connections are made on the DBus if a new user registers
  9. 26th July - 3rd Aug: Create method to receive the info about the objects they export.
Phase -III(Final Testing)
  1. 3rd Aug- 13th Aug: Final Testing of all the patches submitted

This is just a tentative schedule of deliverables. However there should be allowance of 2-3 days. 
I would like to mention that if selected, I will be willing to continue the project work even after GSoC. I will work with complete dedication to ensure that the code is pushed to a stable version as swiftly as possible. Additionally, even after GSoC, I plan to actively maintain my code by ensuring that it is updated and bug-free.

Do you have other obligations from late May to early August (school, work, vacation, etc.)? Please note
that we expect the Summer of Code to be a full-time, 40-hr a week occupation. It is important to be clear
and upfront about other commitments that you may have during that time.

Since my institute will be closed for summer break from 1st June to 31st July, I will be able to devote more than 56 hrs per week for the summer of code project. Additionally,even in August, I will be able to commit 40 hrs a week for the same. Moreover, during the duration of course, I won't be involved in any other project or activity.

About Me:

I am a B.Tech 3rd year student pursuing Software Engineering from Delhi Technological University, Delhi, India. I aspire to pursue research and development in Computer Science as a career. My primary areas of interests lie in Linux/FOSS development. I have developed a strong hold on programming languages Qt and C++.

I was introduced to the KDE development in KDE-Summer Of Code 2011 where I worked on Payment Detection Use-case of Alkimia under the guidance of Alvaro Soliverez, Klaas Frietag and Thomas Baumgart. I am presently working with Daniele Elmo Domenichelli on Kwhiteboard to port it to the new API. I have had a great experience while working with KDE Developers and would like to continue working with them. Please have a look at my resume or website for more information about my projects and achievements.