When an actor comes to me and wants to discuss his character, I say, “It's in the script.” If he says, “But what's my motivation?”, I say, “Your salary.”
For a long time, communication devices were dumb. When I wanted to call a friend, I would take out my paper organizer and look up the phone number. Then I would punch it into the phone, getting just the desired results. And when my friend suggested a date, I would take a pen and note it in the same organizer.
But the times have changed rapidly. Today, I do not have a paper organizer anymore, I have a Palm Pilot™. I do not type in numbers into my phone anymore, it has an address book. So does my phone at work, and of course my mobile phone. And this is where the problems begin:
Whenever I get a new contact, I have to enter his phone number three times. After all, I want to be able to reach him from home and work, and of course from my mobile. Ok, you might say, most of my work contacts I would not call from home and the other way round, but this is just evading the problem instead of solving it. A real solution would be to let those Personal Information Manager (PIM) devices talk to each other.
And such software really exists. I can synchronize my Palm address book with MS Outlook, or with Gnomecard. I have even found software for synchronizing my mobile phone with MS Outlook or with the Palm address book. So the current solution is to adopt every single PIM device to work with every other single PIM device.
Obviously that this is not a very good solution. One good solution would be to standardize the synchronization protocol and to standardize the data being synchronized. The goal of this thesis is to analyze one of theses approaches and to try to implement a fully working version.
This solution comes mostly from the vendors of mobile phones and PIMs. They were tired of supporting every single product. So most of the larger ones (Ericsson, IBM, Lotus, Matsushita, Motorola, Nokia, Openwave, Starfish Software and Symbian are mentioned on the SyncML web site http://www.syncml.org) started and sponsored the SyncML project.
According to its web site, “SyncML is the leading open industry standard for universal synchronization of remote data and personal information across multiple networks, platforms and devices.” In reality, SyncML is the only industry standard for synchronization of PIM data.
SyncML defines a basic client - server interface for exchanging personal data. Basically, any devices can act as a server or a client. The requirements for a server are much higher, though. And to avoid complete data confusion, this approach leads to one central server.
The SyncML standard describes only the way data is exchanged, but not the format of the data itself. Is does, however suggest some formats, such as vCalender and vCard and even requires them for certain applications. SyncML itself is described in an XML syntax.
Since SyncML is supposed to be an “open” standard, the suggestion may occur, that there are already some open tools for it. There is a reference implementation and some java projects that will be discussed later.
And this is where the brave new world already ends. There is currently no working, fully implemented C or C++ library. And when it comes to common open source projects such as Gnomecard or Kab, none of them implement SyncML, not even as client. And when it comes to a server back-end with a real scalable database, there is yet an open-source implementation to be made.
To build a prototype this project has therefore to design and to create a SyncML application. In particular, the goals are to:
create a full SyncML featured C++ library, that implements all requirements for SyncML 1.01
adapt an existing open-source PIM client to use this library for acting as a SyncML client.
write a full featured SyncML capable server which is able to store calender data.
SyncML is an event based protocol. The library must have a way of calling back into the main program and of selecting explicit data record without having to know their content. The basic idea here comes from another XML programming implementation: SAX. In SAX, the parser itself is an object. Whenever an event gets fired, the appropriate method gets called. A programmer has to extend the basic parser class and overwrite the methods that need to be customized.
The same idea will be used in the SyncML library. Ideally, all configurable parameters and functions have reasonable defaults, so that the library can be effectively used out-of-the-box.
With this library, the client part is actually pretty easy: Both, Gnomecal and KOrganizer, store their data in the standard vCalender format. So an application, which reads a vCalender file and synchronizes it, will meet the requirements, and would be even more extensible.
Unfortunately, the same is not completely true for the address book data. Gnomecard uses the standard vCard format, and will therefore be supported. Kab on the other hand uses a proprietary format, which would need more customizing.
The server application has other issues to solve. To be able to sync data, it must keep complete logs which data has changed on which client. This data is needed to determine which entries must be synchronized. Also, the server must remember which clients it has previously synced to. There is a lot of data to store about the client: type of client, its capabilities, local UIDs, etc. Whenever the same data has changed on more than one client, the server must have a way of finding out which new data to keep and where to merge.
Keeping all this information in the server leads to another important issue: The data structures must be capable of holding all this information. The question is, how detailed the change logs have to be, which information is kept about the clients, etc.
To conclude, the necessary steps are:
Design a concept for a complete client - server architecture for distributed management of PIM data
Design data structures, especially on the server for keeping the information
Define, how the clients and server actually connect
Implement the SyncML protocol
Implement a client and server prototype