I just committed the first version of a working GObject binding to the Conduit DBus API. You can check out an example test program here.
Contrived Example-like Code
/* The running conduit app/daemon */ ConduitGApplication *application = conduit_g_application_new (); /* Get two dataproviders, a datasource and datasink */ ConduitGDataprovider *source = conduit_g_application_get_dataprovider(application, "TestSource"); ConduitGDataprovider *sink = conduit_g_application_get_dataprovider(application, "TestSink"); /* Put them in a conduit so we can sync them */ ConduitGConduit *conduit = conduit_g_application_build_conduit(application,source,sink); g_signal_connect (conduit, "sync-progress", (GCallback) _sync_progress_cb, NULL); g_signal_connect (conduit, "sync-completed", (GCallback) _sync_completed_cb, NULL); g_signal_connect (conduit, "sync-conflict", (GCallback) _sync_conflict_cb, NULL); /* Add it to the GUI so the user can see it (optional) */ ConduitGSyncset *gui_syncset = conduit_g_syncset_new(application, "/syncset/gui"); conduit_g_syncset_add_conduit(gui_syncset, conduit); /* Perform the sync (boom!) */ conduit_g_conduit_sync(conduit); g_main_loop_run (mainloop);
Conclusion
- A GObject binding to the Conduit DBus API means you can synchronize your application data, from within your application, in very few lines of code;
- Your application is not going to crash
- Your application is not going to hang or block the UI
- The difficult sync logic for interfacing with various other places can be written in Python (faster, more productive, most web-services get python bindings first), live in the Conduit source tree, and immediately be available to all other applications which use Conduit to sync stuff.
- In SVN NOW!
- Hat-tip to Mikkel Kamstrup Erlandsen whose Xesam Glib bindings provided a useful starting point, and saved me much autotools pain.
- Yes, the names are a bit long.Who has a better idea for the prefix, gcond_ perhaps?
- Who wants to help me integrate this into;
- Cheese
- Evolution
- GNOME Phone Manager
- $YOUR_APP_HERE
That looks quite cool, I am looking forward to a future where all my data is synced across all my boxen.
Just a quick question… Is conduit started by DBus activation? If so you could do some nifty dbus connection checking and shut the daemon down when no one uses it. Just a thought (you may already have had :-)).
You can see how I do connection tracking in xesam-tools (http://xesam.org/people/kamstrup/xesam-tools/) in xesam/server.py - the SearchServerStub class.
‘Glad to see that you found use of xesam-glib
@Mikkel:
Yep its auto-started ATM (without the gui, in daemon mode only). Thanks for the awesome tip, I have been pondering on how to do connection tracking for some time now
Uh, bright the future is
Serialization is occasionally called “pickling” in other programming languages, so I humbly suggest that you use “gherkin” for the namespace.
gcond_ might not be the best prefix, as we already have GCond in GLib for thread synchronization. I’m fine with conduit_, but if you really want it shorter, I suggest looking into an acronym, e.g. csa_ (Conduit Synchronization Architecture) or something similar.