OSP: Architecture

Architecture

After some extensive reading, I am convinced that the SyncML initiative offers the best solution and it should be at the cord of the framework. Here are some things going for it:

It was co-developed and it supported by some real industry giants, especially IBM. Sorry, but in my book IBM stands for some of the soundest architecture and technology around.
The protocol has provisions for all sorts of options, communication details, conflict resolution options, and even authentication procedures. I'm willing to bet the people who designed SyncML know a hell of a lot more about this stuff than I do, and their experience was leveraged in the design of SyncML. I trust it better than I trust myself to do something completely homegrown.
It is a standard. It always pays to stick with standards for interoperability. It is also natively used my many new cell phones on the market. Implementation of SyncML will assure that a minimal amount of additional coding will be required to create some conduits.

I will not take this time to go into any of the details of SyncML, although I will mention an important note that it depends on the following protocols to embody contact, event, and task information:

vCard 2.1 (mandatory support for SyncML)
vCard 3.0 (optional support for SyncML)
vCalendar (mandatory)
iCalendar (optional)

Of these, vCard 3.0 and iCalendar are the most modern standards. Unfortunately, I've been unable to find some nice generic "open" libraries to handle these formats. There are some libraries out there but they are either incomplete, they are integrated into some platform (eg. requiring KDE libraries) or they don't have flexible licenses. So I think one of the first steps in this project will be to write parser/lexer libraries in lex/yacc (or GNU's flex/bison) for import and export.

Also a small stumbling block (although not as immediate) many PDA or cell phone manufacturers use a binary form of XML (to compress the data streams further) called WBXML. A library will be needed that can convert data streams in either direction. It will only be needed for devices that require it, so we may be able to avoid its use for a while. There's also a library someone wrote, I'll have to investigate further to see if it has a compatible license.

Here is a diagram of the architecture I think would be best suited for the project. I've taken pains to make sure that truly platform and language-neutral libraries can be isolated so only specific, isolated code would have to be written to integrate the system into any platform. (GUI controls, networking integration, etc.)

With this framework in place, if someone wanted to add any device (PDA, cell phone) or application (E-mail program, address book, browser, Palm conduit) or service (synchronization backup server, LDAP server) he or she would simple be restricted to writing a Conduit Interface Module and/or a Conduit Transport Module. In many instances these may be reused. If someone writes a Conduit Transport Module for Windows that performs cell phone synchronization via BlueTooth (for SyncML enabled phones) that module may be reused for many different phones and can be used to create a simple bridge between many different possible applications and the cell phone.

Conduit Interface Module

For good architecture, the CIM must adhrere to the following simple rules: it must restrict it's communication with other sync devices to the SyncML library API that we will design. This API will provide functionality for callback functions (if we decide that's needed) so the module can be triggered by outside events. The CIM must also restrict its access to contact, event or task information through the vCard, vCal, etc. libraries. In other words, the structure of PIM (personal information management) objects must be delegated to these libraries. Beyond these restrictions, the Conduit Interface Module can use any language, libraries or platform-specific code it needs to interact with the actual device, program or service to manage or change the data.

Conduit Transport Module

The CTM has the sole responsibility of moving a data stream between the SyncML library (in the form of SyncML-encoded data, with or without WBXML binary encoding) to its final destination. This module must have no dependency on the data being brokered back or forth (it must not read, interpret or depend on the actual information) but rather treat it as a generic data stream. It will decide whether HTTP or OBEX are used as a transport protocol. It will coordinate opening a BlueTooth interface, etc. The module may also do nothing more than set up a two-way Unix socket to allow communication between two different applications (like an address book and a Palm Conduit). This may require some lightweight libraries to create a standardized way of accessing OS-provided HTTP, OBEX, etc. services. We'll determine the specifics of that down the line.

Configuration Information

It may be a good idea to restrict the conduits to saving their information in a standardized key-pair format similar to OS X plists or Windows registry trees so that another standardized very-lightweight library may be used to store configuration information. (Authentication details, synchronization options, etc.) This would have the advantage of better-seperating GUI-specific configuration controls and the conduit, increasing the reusability between platforms. Remember: we want a system very similar to the iSync framework that will allow easy migration between any operating system.

Subverting the SyncML Step

Although it's obvious that I'm pushing SyncML as a central component of the OSP framework, if one absolutely refused to adopt SyncML or had an instance in which it simply could or would not fit within the SyncML framework, one could write a pair of conduit modules (a CIM and CTM) that are simply designed to talk to each other. Personally, I'd like to avoid such a scenario, but it at least provides options.

Next: Part 3 - Road Map

site issues, problems or corrections? contact webmaster@murraywilliams.com. Page last updated 29-aug-03 12:50