29
Mar
08

New Conduit Features

Last week (or so..) I released Conduit 0.3.9, the notable features of this release were the addition of documentation, and dramatically improved support for removable devices, like USB keys and portable hard drives.

Conduit Documentation

Conduit has always supported removable disks, but the UI for working with them has been dramatically improved. In the screenshot below you will see Conduit automatically suggesting pre-configured dataproviders to sync with folders on the removable device. The use case for this is

  1. Joe synchronizes stuff from one PC to his USB key.
  2. When Joe plugs that USB key into another computer also running Conduit he is presented with a pre-configured method to synchronize information from the usb key to a location on his local machine.
    Preconfigured USB key and mobile phone discovery

The functionality is not all that different to before (it shares all the same code as the traditional folder <–> folder sync, meaning you get conflict detection etc) but the way it is now presented is more sensible and discoverable.

In the screenshot you will also see the first commit of mobile phone support in Conduit. Phone discovery is done using bluetooth. Picture sync is implemented atop gnomevfs-obex-ftp. Data is currently fetched from the phone using gammu, but discussion are underway on how this might tie into gnome-phone-manager (which uses gnokii).

This work is (mildly) separate, but necessary for a sensible SyncML (using libsyncml) implementation. In order to provide smart suggestions on what sync options to offer for a particular phone, phones in range (via bluetooth or USB connection) should be enumerated and their capabilities queried. Currently I am using bluez for the former, and gammu for the latter, however, at least in the bluetooth case, the latter could probbably be accomplished using pure AT commands over a serial socket to get the manufacturer and model number and them comparing this with a database of capabilities.

If its not clear, this is still in the experimental stage, but the current approach seems to demonstrate that Conduits architecture, and the approach to implementation are approximately correct.

There have also been a few other fixes go into SVN, including

  • The ability to create tags in F-spot from within the Conduit UI
  • Improved configuration for picasa web galleries

Finally I will finish with a dear lazyweb…..

Dear Lazyweb; The current implementation of network sync doesnt really scale to pushing large files around. Its using the python pickle module, which has a tendency to read everything into memory, base64 encode it, run out of memory, and then explode. I have considered may ways to solve this

  • Use sftp - but that requires the user setup a ssh keypair with the other computer. Seahorse, can you give me a dbus interface to make this happen, easily?
  • Re-implement (because the license is CPL), some of the ingenious performance optimizations in conary WRT decreasing XMLRPC memory usage.
  • Wait for the GNOME desktop to offer some sort of GiveFileToThisUser() dbus api call. Could perhaps be implemented atop Giver/Telepathy (if… it gets accepted to the desktop….)
  • Custom python module written in C to do this….
  • Continue doing what I am doing, and wait for people to complain louder….

10 Responses to “New Conduit Features”


  1. 1 David Adam March 29, 2008 at 5:18 pm

    Python pickles are also a bad idea to punt around over the network if you don’t absolutely trust the sender of the pickle. This means you need end-to-end encryption and authentication.

  2. 2 infodroid March 29, 2008 at 10:21 pm

    Assuming your data is binary, your network file transfer should be possible using simple socket connection based on SocketServer. Once you have sockets opened, you dump bytes from one point and read them from the other. You can also use wrappers around libraries that already do this. For example pyOpenSSL.

    If your data is not binary, but structured in some way, I would highly recommend doing something with XMLRPC. Its a breeze in Python.

  3. 3 ssam March 29, 2008 at 10:40 pm

    I would vote for sending data over ssh. everyone trusts that it is secure.

  4. 4 Tadeu March 30, 2008 at 6:04 am

    good work
    thanks

  5. 5 FaberfoX April 22, 2008 at 11:25 pm

    John, thanks a lot for conduit, it’s amazing and can’t wait for the maemo version.
    Just one quick question, do you plan to support alarms for evolution google calendar?

  6. 6 Mythulto April 25, 2008 at 2:10 pm

    I liked Conduit 0.3.4, but I did a download/config/make/make install of 0.3.9 and can’t get it to run. Is there somewhere to get support?

  7. 7 SilverTail May 17, 2008 at 6:58 pm

    I See that Conduit 0.3.8 has been included as a part of The PcPlus [#268 2008-05] Essential Collection-Selected Linux software”

    Congratulations

  8. 8 Gatonegro August 27, 2008 at 7:45 am

    I think that SSH support — especially through sshfs — is vital. If you want to update over the network two PCs,SSH provides standard and encrypted communication.

    It wouldn’t be that hard to do, besides, provided that both machines have a fixed address or a network name: You’d just need to provide the user with a box for commands to execute before and after running conduit. That’d allow to mount and unmount the sshfs.

  9. 9 Matt August 5, 2010 at 11:38 pm

    Just chasing this up - I’d love to see ssh-based network sync in Conduit, as I want to be able to sync between home desktop and laptop from different places around the world, and this missing feature means I’m having to stick with unison for now. Thanks!

  1. 1 New Conduit Features Pingback on Mar 29th, 2008 at 3:38 pm

Leave a Reply