Trac is being migrated to new services! Issues can be found in our new YouTrack instance and WIKI pages can be found on our website.

Changes between Version 6 and Version 7 of GSoC2010/DetachableLibpurple


Ignore:
Timestamp:
Sep 5, 2012, 3:27:42 AM (11 years ago)
Author:
datallah
Comment:

Change viewmtn reference to point at hgweb

Legend:

Unmodified
Added
Removed
Modified
  • GSoC2010/DetachableLibpurple

    v6 v7  
    66Let'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.
    77
    8 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 :)
     8You have 3 clients running, and each have a separate account or handle. Wouldn't it be great if all of these clients were synchronized using the same connections, displayed you the same buddy list and chat logs? Well, that's what detachable sessions allows you to get :)
    99
    1010== The idea ==
     
    1212
    1313== Goals ==
    14 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.
     14This 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 remotely, using ssh or an export display.
    1515
    1616
    1717= Current status =
    18 == Monotone ==
    19 Current state of this work can be followed in the '''[http://developer.pidgin.im/viewmtn/branch/changes/im.pidgin.soc.2010.detachablepurple im.pidgin.soc.2010.detachablepurple]''' branch. You can check it out following [wiki:UsingPidginMonotone#GettingStartedwithPidginmonotone the monotone guide] and using my branch instead of im.pidgin.pidgin.
     18== Mercurial ==
     19Current state of this work can be followed in the '''[http://hg.pidgin.im/soc/2010/gillux/detachablepurple/ detachablepurple]''' repo. You can check it out following [wiki:UsingPidginMercurial#PublicRead-onlyAccess the mercurial guide] and using my repo instead of the main repo.
    2020
    2121== GSOC and after ==
     
    2727But if you really want to see something and you know how to use a command line, you can play with what's available:
    2828
    29 1. Follow [wiki:GSoC2010/DetachableLibpurple#Monotone this] to get the source.
     291. Follow [wiki:GSoC2010/DetachableLibpurple#Mercurial this] to get the source.
    3030
    31312. 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.
     
    41417. Run as many other pidgin sessions as you want repeating step !#4.
    4242
    43 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?
     43Now you can try to manipulate the ''Accounts'' window of all the running pidgins and finchs, and see that they are synchronized. Awesome, isn't it?
    4444
    4545== Applications that uses libpurple ==
     
    7171 * '''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.
    7272 * '''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.
    73  * '''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.
     73 * '''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.
    7474
    7575== For the remote version ==
     
    7777
    7878== Communication ==
    79 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 [http://fr.dotsec.net/~gillux/detachable_sessions2.svg this drawing].
     79DBus 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://fr.dotsec.net/~gillux/detachable_sessions2.svg this drawing].
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!