Previous: Part 2 - Architecture

As you will soon see, I'm a list freak. The following sections break down my idea of the best road map for getting this project off the ground. Again, this is version 0.1 style documentation.

Prerequisite libraries

Carefully-designed APIs

Initial Conduits

Expertise Needed

Prerequisite Libraries

We need to design the following libraries before the OSP framework can be assembled. This is really the first step of the project. These libraries should be very language neutral (GNU style C) and intended for reuse so we can attract outside development interest.

vCard/vCal/iCal parser/lexer libraries

Libraries must exist to parse any legal vCard, vCalendar or iCalendar files, trigger appropriate exeptions for malformed data, provide the parsed data through a standardized API, and allow the reverse (saving/export) to be done. I believe using the standardized lex/yacc (for GNU, flex/bison) is the best way to go, although I'll entertain anyone's argument to the contrary. I believe these should be simple generic C libraries, with the possibility of having C++ (and maybe Python, etc.) wrappers down the road with a simple inheritance model. We want to provide the ability for these libraries to be used by other people in other projects because IMOHO if they are generally useful they have the greatest chance of attracting outside expertise in maintenance and improvement. They also then have the greatest likelihood of finding their way into some standard OS libraries for Linux or Darwin. These libraries should not be restricted to being useful for the Open Synchronization Project!

WBXML library

This library will convert between XML (ascii encoded) and WBXML (binary encoded) data streams. One alpha-quality library already exists. We have to see if it exists under an acceptable license. Further info later.

SyncML library

We need to go through the SyncML documents and create a reference implementation. This will be the real meat of the OSP. A top-notch API should be designed so that our Conduit Interface Modules do not need to know anything about the actual SyncML standard protocol. I'm not sure about the separation between the actual SyncML reference implementation and it's API interface. I think a good separation will again allow our SyncML library to be used by other people, thus bringing in more outside cooperation. It would also allow multi-lingual wrappers (C++, Python, Java) to be designed. This might even allow multi-lingual conduits to be written, assuming our vCard, et al. libraries are similarly crafted.

Transport Libraries

We should try to make some lightweight transport libraries that can offer the Conduit Transport Modules a simple reusable interface and handle the custom requirements of the platform for getting data brokered through TCPIP, BlueTooth, serial ports, etc. If an operating system has good HTTP or OBEX API's on the OS level, we should use them. (Especially if the OS will offer a centralized configuration for handling proxies, VPN's, etc.)

Carefully-designed APIs

I know the value of good architecture. In my opinion it can make or break a project, and it can make the difference between brilliant and shitty platforms. (Case in point: Windows .vs. NeXTStep/OPENStep/OS X Cocoa.) There are some people who dedicate their lives to studying examples of good and bad architecture and have tried zillions of different frameworks. God do I want someone like that working on our APIs.

If we don't find such a master, everyone on this project must be ready to face the possibility of completely throwing out our first attempt, and maybe our second attempt at an API until we get it right. I will not push shitty legacy code, and I'm sure there's going to be some real trial and error going on here!

Initial "Sample" Conduits

Here's a list of the possible conduits that can be developed once we have the framework in place. In many cases I think these conduits would be almost trivial to develop. (If so, that would demonstrate how well-designed our framework was.)

Address Book (Mac)

Using the published Mac API, it should be possible to access and alter the address book. If we're lucky, this may be our tie-in to Apple's iSync by using the Address Book as the nexus between the two systems.

LDAP Server (OpenLDAP, all platforms)

A conduit that allows synchronization to an LDAP server anywhere on the network, thus providing quick AB functionality to may e-mail clients.

Central "Backup" Server

A network service whose sole purpose is to store all data and offer a network-based central node for synchronization between computers. (Similar in function to Apple's .Mac service.) This may be a front-end to a MySQL database, or maybe some even lighter-weight like a Posix database (gdb).

MS Outlook

Use of the MS VBA API for Outlook to synchronize contacts, calendards, etc.

IE Bookmarks

If I remember, Internet Explorer bookmarks are simple URL files in an individual's "Documents and Settings" folder. This would be simple for a bookmark conduit.

Palm Conduit

A lot more advanced, this would be an important step especially for the Windows Platform.

MultiSync Conduit

The Gnome MultiSync project has some momentum and would make a natural link-in for Gnome and especially Evolution users. MultiSync web site mentions work on a SyncML conduit. Once that's done this should be a no-brainer!

Apache Server Module

Use Apache as the primary interface for the Conduit Transport Module, thus allowing your web server to double as a friendly-neighborhood sync server.

Mozilla Conduit

For anyone with the bravery to dig into the Mozilla project, this could synchronize both bookmarks and address books. It also has the benefit of spanning all platforms. Possibly as important (and as challenging) as doing a Palm Conduit.

BlueTooth Cell Phone Conduit

This should be easy for SyncML-enabled cell phones. I'm sure some phones also work over a USB or serial cable that would be similar in nature. This is probably very platform specific code, although it would test the quality of our transport library designs in terms of how portable the condit was.

Address Standardization/NCOA Service Conduit

In my recent work with some non-profit organizations I've learned oodles about "address standardization". In essence, the US Postal Service has really one and only one truly official representation of your mailing address(es). The closer you are able to use the "proper" standardized form of an address, the more reliable (and quick) the postal delivery. There is some phenominal software at affordable prices that will correct common errors, standardize addresses, and provide ZIP+4 9-digit zip codes (actually 11 digit if you count the DPC), CART codes, counties, even congressional voting districts. One could provide a for-pay service of combining a Sync Server Internet service with address standardization/correction services. Additionally, one may be able to offer NCOA (National Change of Address) service. What this means is that if my friend Tom moves to another address and fills out that little USPS forwarding form, a few weeks later my address book might just "auto-magically" get updated with his new address.

Expertise Needed

If it comes down to me writing everything, nothing is going to get done and the resulting product will probably suck as a bundle of duct tape and bailing wire. Below is a list of the skill sets and volunteer jobs that need to be filled wherever possible.

GNU "autoconf, etc. framework" setup

This should be structured as a standard GNU project for platform portability. That means having all the standardized files for autoconf, etc., platform and library detection, standard TODO, LICENSE, README, INSTALL, CHANGES files, etc. I have no experience in setting these things up, although I've typed "./configure --help" a million different times and built all sorts of Open Source applications that way. I'd rather not take the time to learn all this stuff if someone is already familiar with it.

Architecture Masters

I've already ranted about this. We need good architects to make this system (a) portable and (b) plug 'n playable. IMOHO good architecture is the first designator between success and failure.

Website management, status document maintenance

The health of a project is usually first noted in how frequently the web site has been maintained, how well the documents reflect the daily or weekly progress, etc. Projects with the appearance of vitality attract usrs and developers. Projects without current web site maintenance have the reek of death. IMOHO regular site maintenance is more important that good site design. Also, if we get any level of activity in this project, CVS maintenance and maybe even a Bugzilla server would be beneficial.

Documentation

This goes without saying. If documentation is started early, the usability of the utility is vastly improved. Those who can't code can always make a contribution by documenting.

License Advisor

In the beginning we will need to rummage through existing libraries to see if anything is reusable. (Although my initial exploration doesn't show much promise.) We need license compatibility with whatever we might want to reuse. We could also stand to use someone who can help the project team to decide on the best possible license. My personal criteria is for something that will maximize the potential of this system finding its way into software distributions (like Red Hat), getting integrated into existing software projects (like Evolution), and having components (vCard libraries) readily scavanged by other projects. I would also like pieces to be usable by commercial products rather than having the stench of a "GPL virus". Obvious candidate models are LGPL, BSD, Mozilla licenses. Finding a good expert with realistic advice would be very helpful.

Wish List

This section right now is just a place for me to jot down those features I'd like to see in a finished product. These are some things that don't exist with other Sync systems that I really would love to see.

Group Designations, Subscriptions

I don't know of any instances where contact lists (and/or calendars) are easily shared between or organized into groups of people. I would love for my circle of friends (or employees of an organization) to share an address book, propogate changes of information, etc. For example, if my friend Dave finds out that my other friend Tom just moved and got a new telephone number, wouldn't it be great if by modifying his address info for Tom the same details would ultimately find their way into my address book? It would be similarly nice for me to have to option of subscribing to entire contact lists for a department, group, theater cast/crew, etc. There may also be an access contol list devised so some people have read-only access to changes.

Full support for photographs and pubic keys/certificates

I'm an avid photographer and keeps lots of digital images of my friends. Many I've (manually) imported to my cell phone so I see a picture of a caller's face when I get an incoming call. Similarly I have snapshots of people (when possible) in my OS X address book. I'm also a fan of computer security and I have both a PGP public key and SMIME certificate. I would like this system to fully integrate with an organization's security infrastructure where possible. Both photographs and public keys are supported by the vCard 3.0 specification, but rarely used.

Address Standardization / NCOA

See the entry in the Conduits list. This would be a service I think people would LOVE and I'm amazed it hasn't been offered already by Apple, Yahoo!, etc. for all their for-pay services.

 

Back to the OSP Homepage

written materials and original images copyright © 2003 by Murray Todd Williams

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