Aug 16, 2007
After a short hacking hiatus, soul searching, and general uncertainty regarding Conduits place in the Gnome Online Desktop plan, we the Conduit developers have decided to keep doing what we do best; adding awesome features, and making Conduit into the best desktop synchronization service for the free desktop. I invite you all to spot the new features in the image below;
Going through the new features one by one;
-
The Network datasink - thats how you tell conduit to share data to other people on the network
-
The chad.local dataprovider - ... and thats how you'll choose to consume other peoples shared data
-
The evo2-sync dataprovider - before long you'll be able to use opensync plugins in conduit
-
The f-spot dataprovider - before long that will be two-way and networkable, work is ongoing with upstream
-
Always-Up-To-Date is on the horizon (i.e. auto update and sync changed data)
-
iPod photos support - our patches are accepted upstream, so soon we will support those too
-
The facebook dataprovider - just photos so far, but more facebook features will be exposed soon
Other than those Massive New Features, there has been continued bug fixing and some improvements to the DBus interface to make it more Havoc Compliant. Check out the sample below for how to use Conduits DBus interface to synchronize things...
bus = dbus.SessionBus()
#Create an Interface wrapper for the remote object
remote_object = bus.get_object(APPLICATION_DBUS_IFACE,"/")
app = dbus.Interface(remote_object, APPLICATION_DBUS_IFACE)
#get a dataprovider
path = app.GetDataProvider("TestSource")
source = dbus.Interface(
bus.get_object(DATAPROVIDER_DBUS_IFACE,path),
DATAPROVIDER_DBUS_IFACE
)
#get another
path = app.GetDataProvider("TestSink")
sink = dbus.Interface(
bus.get_object(DATAPROVIDER_DBUS_IFACE,path),
DATAPROVIDER_DBUS_IFACE
)
#get a conduit
path = app.BuildConduit(source, sink)
cond = dbus.Interface(
bus.get_object(CONDUIT_DBUS_IFACE,path),
CONDUIT_DBUS_IFACE
)
print "Synchronize the conduit"
cond.Sync()
I have written an example which shows how to use Conduit to upload photos to any of our supported photo sites with even fewer lines of code. The DBus API documentation lives at the top of this file. Dont forget that by using a desktop wide sync framework you get all the Conduit bling for free, including
Jun 7, 2007
Conduit
For all those that are interested I just released Conduit 0.3.1, the second development release in the series. The release includes a heap of bug fixes and some interesting new features including;
Goals for the next release include
The thing that keeps me interested in conduit is the speed at which we are progressing. Each new dataprovider added has a benefit proportional to the number of already included dataproviders; for instance adding evolution support opened up the ability to do tomboy notes <--> evolution memos, as well as evolution memos <--> ipod notes, etc.
Gnome Link Drop
Here are some interesting things on the horizon that made me excited about GNOME and gtk. Delegated to people with more free time and ability than me!
Anyway, Im still on holiday, and loving it!
Mar 10, 2007
A lot has been happening on the Conduit front of late, and I probably should have blogged about it earlier. Unfortunately, it has seemed as though I have made 5 steps forward and 4 steps back with every hour of work on the project, so why, and whats up?
Background
I will be dropping a 0.3 release to coincide with the release of GNOME 2.18. This will be a developer release designed to get things working well before a stable 0.4 release some time after.
All of Conduits synchronization capability is determined at runtime. Conduit scans the users' and the system wide dataproviders directories in the same way that Deskbar loads handlers when it starts. The core synchronization logic is decoupled from the dataproviders, and only those relevant dataproviders are shown to the user (i.e. only show iPod Notes if an iPod is connected, etc).
Remember that I want Conduit to be a GNOME wide synchronization service that other applications can hook into, so I need to not only decouple the core sync logic from the application and usage specific dataprovider back ends, but also allow conduit to be extended by third parties.
Extension by 3rd Party Applications
I mentioned that all synchronization capability is determined at runtime. The other half of this story is that a third party may wish to synchronize something that Conduit knows nothing about (I'll use a Jokosher project as an example, although in my next post I will address these issues in the Tomboy case). Lets assume that a Jokosher project cannot be described in terms of the basic types of data that Conduit knows about (email, contact, file, etc). In order to allow Jokosher projects to be synchronized between different computers the Jokosher developers would need to do the following
-
Define a Jokosher datatype that describes what it is to be synchronized.
-
(optionally) Define some conversions between the Jokosher datatype and the basic Conduit datatypes (File, Text, etc)
-
Define a dataprovider that encapsulates Jokosher invocation specific information such as the Jokosher user, and how does one go about extracting/modifying Jokosher specific data when Jokosher may be running.
The Conduit framework will do a lot of heavy lifting here, such as caching modification times, providing a way for the user to configure a Jokosher sync partnership, providing a way for a user to resolve conflicts, and even allowing the whole sync process to be controlled from outside of the application over DBus. Most interestingly however, depending on the fidelity and number of conversions specified in #2, Conduit will facilitate a number of other useful sync scenarios including,
-
Sync Jokosher projects via any gnomevfs compatible location (ftp, etc)
-
Sync via Amazon S3 (coming soon)
-
Sync via USB key
-
Sync directly over a local network using Avahi. (next release)
The point here is that this decoupling of the dataproviders, from the core and the datatypes (sans the conversion functions) lets the Jokosher dataprovider take advantage of any/all additional $FUTURE dataproviders (e.g. Amazon S3) and all improvements to the Conduit core (such as direct sync using pickle'd python over network via Avahi).
Testing
As I get closer to release I get more nervous about releasing a tool which will could eat peoples data. To mitigate this risk I spent a week or two implementing an extensive testing framework for Conduit, a task I should have tackled much earlier in the project.
Unfortunately the testing is made more complicated when the applications capabilities can change between invocations (dynamic loading of dataproviders and conversions explained earlier). Aside from the usual unit level tests (does this throw the correct exceptions, etc) I am also required to test the fidelity and accuracy of the conversions between datatypes (round trip comparisons), and the fidelity of synchronization from dataprovider $FOO to dataprovider $BAR via any of these datatypes.
The testing framework uses a mixture of python and shell script, and is even web 2.0 compliant ;-). It currently tests available conversions, saving and getting data from various dataprovider back ends (Flickr, gnomevfs, Tomboy, etc). It even does code coverage and pushes the results on line.
What's Next
I apologize for this post being mostly academic in nature, lacking in screen shots. I will post again in a few days with some more relevant information (from a users perspective). I just wanted to highlight how and why I believe a desktop sync service is useful, and how I am trying to satisfy this in a sustainable way for the GNOME platform as a whole.
I anticipate finishing up the two way Tomboy support (via iPod notes, gnomevfs location, and backpackit.com) in the next few days. There are some bugs preventing running Conduit on Feisty (goocanvas 0.6.0 is ABI incompatible with 0.4.0). There are also some other lose ends (like some GUI blocking calls in conflict resolution, and some difficulties saving program configuration). Unfortunately, like a lot of FOSS, the best is always just around the corner....
Feb 6, 2007
When Tracker was proposed for GNOME 2.18 I was one of its staunchest supporters, arguing that a GNOME wide unified metadata storage system would enable a richer desktop experience, and take GNOME beyond its competition. Tracker did not make the cut for GNOME 2.18, and will no doubt be proposed again for GNOME 2.20.
To help people see the potential of a GNOME desktop using Tracker I have been working on two projects for the past little while. Both of these are components of my larger vision of a metadata rich GNOME desktop. These initial attempts just focus on making tagging [1] a more consistent experience for all GNOME apps. Consider the examples and screenshots (for a file called nice) below;
-
Freedesktop emblem spec
Allows desktop file managers and indexers to present a list of predefined emblems and tags to the user, and allows these predefined emblems/tags to be installed by third party developers in a consistent manner.
-
Tracker Nautilus Integration
Nautilus using tracker for storage of all tags and emblems.
-
libtracker-gtk
A bunch of gtk widgets that application authors can use to add tracker functionalit to their application.
Industrious individuals could probably find the bzr repositories for the above work, but at the moment it is not quite ready for prime time consumption. Stay tuned for more news.
[1] Terminology:
Jan 26, 2007
Some interesting things have popped up in the FOSS world in the last few weeks. Some of you may have seen these, others may not;
Jan 6, 2007
So its been a while since I have posted but there is some interesting news to report;
-
Conduit has a new developer - confusingly also named John
-
I am speaking at Linux.conf.au both at the GNOME Miniconf and the Main conference
-
I have some interesting Topaz style demos to show soon
-
Conduit 0.3 is going to rock
-
Opensync will be supported (to some degree)
-
The UI is starting to really ROCK, and improved treeview to display dataproviders, and improved canvas performance.
-
I have been working on a python binding to evolution. It is starting to reach the state of being useful and will be supported in the next release. I hope that this library could one day be included in GNOME.
Nov 13, 2006
This wont be a particuarly coherant post, More a collection of links that I dont want to lose, and that others might find interesting. Also some updates on the foo that I am working on.
One of the great things I like about free software is that there is always something exciting around the corner. Sometimes it just takes way to much procrastinating to find out about it. Here are a few things that I am looking forward to in the next 6 months;
-
Xorg 7.2 with RandR - Should make managing multiple monitors painless.
-
i810 Modesetting branch. Thanks intel for your rocking OSS drivers.
-
Simple way to theme colours in GNOME.
-
Some new GNOME infrastructure;
-
Glade-3.1 (single window mode) - Rocks!
-
Nemiver is awesome, and i'm using it daily.
-
I want to play with pigment, I particuarly like the idea of having a built in animation framework, making it easy to create fluid user interfaces; like
-
Photosynth (made by microsoft - credit where credit is due).
-
Canola - WOW thats running on a 770!
-
Aerith - Eeeww thats java (but hot)
-
I have been running Tracker for a long time, and can recommend it to everyone. I would love to see this go into GNOME along with a bung of helper Gtk widgets to make tagging a first class citizen on the GNOME desktop.
-
After the terribly shortsighted Beryl fork its good to see Compiz get a community website. I wish I had a dual screen graphics card to test all the multihead support stuff that DavidR has just added to compiz.
I have also been super busy of late. I have been working hard on Albatross, interfacing with flightgear ad JSBSim, and learning about Eigenstate assignement for controller design. It looks like my next task is to clean up the AVL stuff and start running some code through Matlab to test these theories.
Finally I am back working on Conduit, and it looks like its the right time for stuff to come together.
-
Rewrote the TreeModel stuff to support adding things at run time which is important because....
-
OpenSync just released 0.20 with better python bindings, so I can start to play with cellphones!
-
I added service discovery of other conduit instances using avahi. This will eventually allow things to be synchronized with remote computers directly and transparently over the local network.
-
Started to add ipod support. When an ipod is plugged in new datasinks should become available which will allow you to synchronize your ipod notes and contacts (and possibly photos thanks to GPixPod)
Anyway, thats all for now. Talk to you later or see you at linux.conf.au.
Sep 25, 2006
So I finally got around to releasing Conduit 0.2.0, which, while having many limitations, is relatively useful and safe to use on a daily basis. I have been swaped by university work at the moment, as this is the last week, but I hope to be back developing again soon.
Other Things on the hack-agenda over the next few weeks (months)
Sep 11, 2006
I have been working really hard for the last month on getting the Conduit core to a v0.2.0 ready state.... However after talking to a few people I have decided to delay v0.2.0 by a week to give more time for testing, and to increase the usefullness of some of the included dataproviders (Flickr and Fspot in particular).
The rationale behind this is, however cool an Idea Conduit is, it is only as useful as the things it can be used to sync with. I want this release to make a big splash, so I want the ability to sync with included GNOME apps to work really well. This means focusing a lot of testing on the Tomboy and F-spot datasources, and the Flickr datasink.
I encourage users to check out the latest version from svn to help in testing. In the meantime, here is a screenshot of Conduit running happily on Edgy.
Aug 9, 2006
After a solid month of work I just release v0.1 of Conduit.
Conduit is a synchronization solution for GNOME which allows the user to take their emails, files, bookmarks, and any other type of personal information and synchronize that data with another computer, an online service, or even another electronic device.
This version is the first version which is actually usable so I thought I would release it to gather feedback, particuarly about the GUI, and how people interact with the application.
The next version will bring more bling including
-
Treeview for datasources and sinks. They will be categorised into groups to more easily distinguish between them
-
Threading cleanups so that sync's may be cancelled while in process
-
Flickr datasource and sink
-
Two way sync for backpackit.com and files
-
Gmail dataprovider tidy ups
I am looking for help and interested developers. Check it out!
http://www.conduit-project.org/
