[Pidgin] GSoC2010/DetachableLibpurple modified

[Pidgin]

Page "GSoC2010/DetachableLibpurple" was changed by gillux
Diff URL: <https://developer.pidgin.im/wiki/GSoC2010/DetachableLibpurple?action=diff&version=10>
Revision 10
Comment: Added technical documentation
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: GSoC2010/DetachableLibpurple
=========================================================================
--- GSoC2010/DetachableLibpurple (version: 9)
+++ GSoC2010/DetachableLibpurple (version: 10)
@@ -57,7 +57,6 @@
 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 ==
 {{{
               +------------------+          +---------------------------+
@@ -65,15 +64,55 @@
               +------------------+          \detachable mode/ UI Client |
                                             +---------------------------+
 }}}
+The idea is to have libpurple acting as a daemon on one side, and as a client on the other side. DBus is used as the RPC mechanism. Because I care about security, we may forward the data over a custom tunnel as described in [http://dotsec.fr/~gillux/detachable_sessions2.svg this drawing].
 
-== 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 synchronization''' Modify the daemon's libpurple to get a full synchronization of events coming in and out of all the clients. For example, one client call would appears as an event for the others clients.
+== Technical details about the current implementation ==
+We just forward API calls, object properties and signals between daemon and clients through dbus. The daemon “UI” is located in purpled/, and the dbus code reside in libpurple/dbus/.
 
-== 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.
+Let’s imagine we have a !PurpleFoo gobject in libpurple/foo.c. First, libpurple/dbus/foo.xml contains what parts of !PurpleFoo are exported on dbus. A python script generates libpurple/dbus/foo.xml.h from this XML,
+which is basically a C struct version of the XML. This XML data is called “introspection data” in dbus terminology. Just call purple_object_class_register_dbus_iface() giving this C struct data as
+argument, and all the properties and signals listed in the XML get automatically synchronized between clients and daemon.
 
-== Communication ==
-DBus will be used to make the daemon<->UI client communication. I needed something that support bidirectional 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 [http://dotsec.fr/~gillux/detachable_sessions2.svg this drawing].
+The usual initialization code of !PurpleFoo from libpurple/foo.c gets
+extended by calling two functions from libpurple/dbus/foo.c: one for
+the class and one for the objects. For instance we have
+purple_account_class_dbus_init() called from purple_account_class_init()
+and purple_object_dbus_init() called from purple_account_new(). This
+extra initialization code will do different things depending on the
+running mode flag.
+
+The running mode flag is a boolean field of !PurpleCore which says
+whether the libpurple acts as a daemon, a client, or in normal mode.
+Typical code is if(purple_core_is_daemon_mode()) {...}. The idea is
+that the detachable session functions are common between client and
+daemon, but what gets actually executed internally is different
+depending on the context.
+
+To export a method, we just call purple_object_bind_dbus_callback()
+in the extra dbus initialization part. Simple functions such as
+purple_account_connect() can be directly binded to a dbus method,
+whereas more complex ones requires an extra wrapper function, such as
+purple_account_register().
+
+== What needs to be done ==
+First, gobjectification.
+
+Then, export the gobjectified parts on dbus so that everything is nicely synchronized between clients and daemon. This should be easy as it mostly consists of adding wrapper code.
+
+Other than that, the initialization part of libpurple will need to be
+adapted for the clients. Currently, libpurple gather data from
+~/.purple/ during its initialization part '''only'''. However we need to be
+able to load this data remotely and anytime after libpurple has been
+initialized.
+
+There are two approaches to get the whole thing working. Quick and dirty
+way and clean and right way. Quick and dirty way is e.g. to simply
+replace the call purple_blist_load() by a purple_blist_load_RPC() one that grabs the buddy list from the daemon instead of the local blist.xml. This is obviously wrong because it freezes the UI and cannot handle network errors neither do retries. But it works with very minimal effort. And this is how things are currently done.
+
+The clean and right way is to first initialize libpurple without loading anything from ~/.purple/, and then to get the data from the daemon. I can imagine having a separate Pidgin launcher for detachable sessions, which would prompt the user for the daemon’s IP first, properly show any network errors etc.
+
+And finally, many extra things that don’t prevent detachable sessions from basically working, such as handling of downloads, searching through logs, getting logs of what happened while a client was disconnected etc. This is probably a lot of work.
+
+Also, we need to encrypt and authenticate the data between clients and daemon through a tunnel. Since gdbus allows to run a custom dbus
+server, and to connect to a particular server, it should be possible to
+forward the dbus connection through a custom tunnel.
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://developer.pidgin.im/wiki/GSoC2010/DetachableLibpurple>
Pidgin <http://pidgin.im>
Pidgin

This is an automated message. Someone added your email address to be
notified of changes on 'GSoC2010/DetachableLibpurple' page.
If it was not you, please report to datallah at pidgin.im.