Who wants to see Conduit Network Sync in action then? Here it is! The quality is a bit crap - if you want to submit a better version of this vid you’d make me a very happy boy.
In it you’ll see both of my laptops. The bigger (and older) one I’ll call Fred. And (purely for the purpose of this post) the little one is Barney. The scenario is that Fred has all my data on and I want to get it to Barney and then keep both in sync. As you’ll see in the video, Conduit’s network code is getting to the point where its ready to take on this challenge.
You’re about to witness how data gets pushed from Fred to Barney (2 contacts and a note). You’ll then see how changes are made on Barney and how they get pulled back down to Fred (2 deletions and 2 modifications are made on Barney, and these are synced to Fred).
I really like how the change to the tomboy note I made on Barney is reflected on Fred immediately after the sync - i don’t have to reopen the note or anything! And with the change detection stuff thats starting to land.. imagine as soon as you change a note it could potentially be pushed back to a server or to your other machine!
The network code currently is split in to 3 main modules. Server.py is the bit that actually makes a dataprovider network accessible. It is implemented using Twisted XML-RPC and is a big PITA because it needs to be threaded. Client.py consumes a remote shared dp and plugs it in to the GUI. It is just a standard xmlrpclib client with a few special cases for relaying Exceptions. All the avahi helper foo is hidden in Peers.py.
The next major focus (other than working on the test framework to hammer the bugs out of the network code) is actually making it possible to set which dataproviders are shared from the GUI - at the moment it is hard coded to only share Evolution Contacts and Tomboy Notes.
For more info on this keep an eye out on the spec and the conduit home page.
