Who's working?

This exciting project is done by gillux and mentored by elb.

What's this?

Story

Let's start with a little story. You're at home on your desktop and you have Pidgin running. Then you do a little break, and you go to your bed with your laptop, which is also running Pidgin to keep chatting with your friends. Then it's time to go to work, and you go to your office, where you keep chatting discreetly using Finch.

You have 3 clients running, and each have a separate account or handle. Wouldn't it be great if all of these clients were syncronized using the same connections, displayed you the same buddy list and chat logs? Well, that's what detachable sessions allows you to get :)

The idea

The goal of detachable libpurple sessions is to allow a user to have several running libpurple based applications simultaneously, all sharing the same the same data and connections. This involves having libpurple acting as a daemon and clients like Pidgin and Finch connecting to it. All the connected clients will access and display the buddy list, conversations, and chats. Existing ongoing conversations' history will be visible in Pidgin or Finch when they connect to the daemon.

Goals

This project will be managed in two steps. A cool thing would be to allow the clients to be running on different machines rather than on the same, but this requires to "networkify" all the UI <-> libpurple communication. Such a thing is not simple to do and that's why I will first make it to work with clients on the same machine. This is a minimal goal called minimal version, and having clients on separate machines is an extra goal called remote version. I'll do it if I get the time to. Note that the previous story is still possible with the minimal version if you run the client remotly, using ssh or an export display.

Current status

Monotone

Current state of this work can be followed in the ​im.pidgin.soc.2010.detachablepurple branch. You can check it out following the monotone guide and using my branch instead of im.pidgin.pidgin.

GSOC and after

I didn't manage to complete this project before the end of the 2010 summer of code. But I definitely want this to work, be sure I'll carry out the project after the summer of code (contributions are welcome, though ;)).

End-user usage

The project isn't usable yet.

But if you really want to see something and you know how to use a command line, you can play with what's available:

1. Follow this to get the source.

2. Type ./autogen.sh --enable-dbus && make to compile the detachable branch. Note that you shouldn't type make install because you probably have an existing pidgin installation.

3. Run the daemon typing ./libpurple/purpled/purpled.

4. On the same host as the daemon, run pidgin typing ./libpurple/pidgin/pidgin -r -m

5. Pidgin should says that no accounts are activated. Activate one if you want.

6. If you want, run as many finchs (again on the same host) as you want too typing ./finch/finch -r.

7. Run as many other pidgin sessions as you want repeating step #4.

Now you can try to manipulate the Accounts window of all the running pidgins and finchs, and see that they are syncronized. Awsome, isn't it?

Applications that uses libpurple

To make your fancy libpurple-based GUI to work in the so-called detachable (or remote) mode, first make sure the libpurple you are used have dbus support enabled. Then just add the following code before the purple_core_init() call.

purple_core_set_running_mode(PURPLE_RUN_REMOTE_MODE);
if (!purple_core_is_remote_mode()) {
  /* Setting remote mode failed and an error
   * message were printed on stdout. */
  /* Handle this as you can... */
}

Then use the libpurple API normally. Your libpurple should contact the local dbus server and get synchronised with the purpled daemon. Note that if your have core plugins, you'll probably have to add the dbus cflags to their makfiles to make them compile.

Details of the hack

Here is an outline of how I think to manage this project.

Drawing

              +------------------+          +---------------------------+
IM servers<-->[libpurple] Daemon |<--DBus-->/ libpurple in  \           |
              +------------------+          \detachable mode/ UI Client |
                                            +---------------------------+

For the minimal version

• Daemon wrapper Create a daemon program that basically runs libpurple which activates the configured accounts, connect to servers… This daemon also listens for incoming clients connexions.
• Detached mode Current standalone mode of clients is kept as a default. Add an option in them to run in detachable mode. The aim is to have to change the libpurple API (and hence the clients) as less as we can. Ideally, they would only have to tell libpurple they want to use the detached mode, and then use it as usual. And all these libpurple calls and events are transparently routed from/to the daemon.
• Attaching and detaching Modify the daemon to handle the attaching of a client. It means sending to the client all it needs to be in the current state of the daemon. This includes things like active accounts, buddy list and chat logs. Detaching is much easier but has to be handled aswell.
• Clients syncronisation Modify the daemon's libpurple to get a full synchronisation of events coming in and out of all the clients. For example, one client call would appears as an event for the others clients.

For the remote version

Identify then adapt each part of libpurple which aren't remote-friendly, such as audio and video streams or file transfers. For instance in the latter case, files must be transfered to/from the daemon while it sends/receives them.

Communication

DBus will be used to make the daemon<->UI client communication. I needed something that support bidirectionnal calls and over multiple peers. For remote communications there is a TCP layer implemented. However there are some drawbacks in this TCP layer: the lack of authentication and encryption. I plan to overcome those using a custom tunnel as described in ​this drawing.