This page explains the architecture of Conduit.

• Conduit is written in Python

• To understand how Conduit works, see 'Code Overview'

• To add support for another application/website see 'Writing A Custom DataProvider'

• Remember to check out the online API documentation

• Contributions should follow the 'Coding Conventions'

1. Background

• Things which provide data to be synchronized are called DataSources. For example a PIM application may have several DataSources - email, calendar, notes etc.

• Things which provide locations for data to be synchronized to are called DataSinks. For example Google provides many DataSinks - email, calendar, photos, etc.

• Both DataSources and DataSinks are derived from a base DataProvider class.

• A DataProviders accept and emit their data to be synchronised in the form of classes derived from DataType

• If a DataType emitted from the source is incompatible with that accepted by the DataSink then Conduit attempts to convert the DataType into a more acceptable format before synchronisation. For example if you try and synchronize plain text files with your gmail application then the text files will be converted first.

• Converters are also loaded and discovered at runtime.

This relationship is shown below. The role is shown in the top line while the class responsible is shown in brackets. The SyncManager controls the process and is responsible for managing the multiple sync threads :

2. Architecture

Conduit is a synchronization framework that makes it easy to support synchronizing your data. To do so one must write a Dataprovider which is able to encode and store Data in the appropriate manner. The synchronization engine is decoupled from the Dataprovider backends and the GUI to make this possible.

Conduit has been designed to be exceptionally easy to extend. To enable this most things in Conduit are discovered dynamically when the application is started (like deskbar). The advantage of this is that extending the application is easy, just drop a python file into the correct directory (~/.conduit/modules/ to add new features. The downside of this is that the architecture is a bit more cumbersome.

Both new DataProviders and new Conversions can be loaded at runtime. For example this allows the developer to add support for a totally new online service in just one python file. The developer is free to use the built in types shipped with Conduit or define their own. If you define your own types on which your DataProvider operates then you need to provide a converter which will convert that type into another type which the application (and other DataProviders are aware.

To enable easier management of the dynamically loaded modules both DataProviders and Converters are held in a ModuleWrapper. Debugging

Conduit uses the python debugging module.

To specify the loglevel of Conduit at runtime set the CONDUIT_LOGLEVEL environment variable to the appropriate value, e.g. CONDUIT_LOGLEVEL=CRITICAL conduit/conduit. Acknowledgements

The following applications I borrowed liberally from

• deskbar

• barracuda

• gsteditor

• Jokosher