Level: Intermediate Edd Dumbill (edd@xml.com), Editor and publisher, xmlhack.com
06 Jun 2003 As the final part of his exploration of SyncML, Edd Dumbill surveys the various SyncML toolkits and products, with a focus on open source offerings. At the start of my dabblings in
SyncML, I expected to have to implement a significant chunk of the
SyncML protocol myself. Fortunately, since then two factors have
made this unnecessary: first, the publication of the previous two
articles (see part 1 and part 2) caught the attention of those working on SyncML, and
they've let me know about their work; and second, the increasing
availability of mobile phones and PDAs with SyncML inside has led
to increased activity in this field.
SyncML Reference Toolkit
The SyncML Reference Toolkit (RTK), though hosted on
SourceForge (see Resources), is a relatively well-kept secret. It
was developed by the SyncML consortium itself. Of course, members of
the consortium have their own SyncML-based products to sell. So
while the open-source RTK is a wonderful contribution, it has not
been published too widely, in order not to undermine the business
of the SyncML designers. For this reason, no sample
applications are delivered with the toolkit.
The RTK is a relatively mature
product, and compiles on both Windows and Linux platforms. Linux
users have to do some fudging, however, as little bugs such as
expecting case-insensitive file names are not entirely absent from
the toolkit. The toolkit comprises a comprehensive C library for
creating, sending, receiving, and parsing SyncML messages. It
supports both XML and WBXML encodings, and HTTP (for
synchronization over the Web), WSP (for use over WAP) and OBEX (for
use over IrDA or Bluetooth) transports.
The RTK is accompanied by a
reasonably complete, though not overly detailed, set of API
documentation. Some parts of the documentation seem to be at variance
with the library itself, so be prepared to start poking through the
source and header files. Reflecting the fact that SyncML has so
many components, the RTK is somewhat sprawling. C is, of course, a
superior language for portability, but it struck me as I
investigated the toolkit that something in, say, Python would be a
lot more accessible.
This toolkit seems like a good
choice for long-term SyncML development, especially if you want the
advantages of speed and Windows/Linux code portability. Don't,
however, expect to whip up a quick hack with it. If you're looking
for support, then try the YahooGroups SyncML mailing list (see Resources), as
discussion of the RTK forms the main part of the traffic.
I mentioned earlier the lack of
examples using the RTK. However, one example that is an absolute gem is
provided by Mirko Mrowczynski. See Resources
for details on how to obtain this example. Mirko's Web page is
in German, which helps explain why this example is
hard to find for English speakers. His sample application makes a
good starting point for programming with the RTK.
Summary
Pros: C is a great
common denominator; authoritative source; mature product; active
support mailing list.
Cons: Large API; unfriendly documentation; hard to
get started.
PHP implementation of SyncML Server
The most immediate use you might have for SyncML is to use it to
back up the data on your phone. This is the application that
Nicolas Bougues has targeted with
his implementation of a SyncML server. Nicolas' code is written in
the popular Web scripting language PHP, and uses a MySQL database
for back-end storage. It only supports the XML encoding of SyncML,
not the WBXML one, and was developed against the Sony Ericsson P800
phone. The P800 only performs synchronization over HTTP
connections, either using a GPRS/GSM connection, or when connected
to a computer through its cradle.
To use it you need to download the
scripts (see Resources), unpack them on your Web server, and create
the required database in MySQL. Nicolas' code supports the
synchronization of the address book, calendar, and jotter
applications. The MySQL database stores the vCard,
vCalendar, and vNotes representation of the data. For instance, at
the recent WWW2003 conference in Hungary I dined out with a group
of friends, and made a note on my P800 of what I ate. When
synchronized into the database, it appeared as shown in Listing
1.
Listing 1. vNote of meal eaten at Restaurant Fatál in Budapest, Hungary
BEGIN:VNOTE
VERSION:1.1
DCREATED:20030523T192529Z
LAST-MODIFIED:20030523T211027Z
BODY;ENCODING=QUOTED-PRINTABLE:
food=0D=0Asoup=20540=0D=0Aduck=201690=0D=0Abeer=20590=0D=0A
END:VNOTE
|
While obviously not industrial strength (Nicolas includes
various strenuous disclaimers), this application has set me thinking
about neat things I could do with the phone: for instance, using it
to write Web journal entries offline and send them live via the
database. It's a great starting point for further exploration.
Summary
Pros: Fun and useful way to
start experimenting with MySQL.
Cons: Immature, server-only implementation; PHP not
suited for client-side development; no WBXML support.
Sync4J
When I first investigated SyncML, Sync4J was one of the projects
I checked out. At that time, no releases had been made. In fact the
first beta release of the software was made very recently, at the
beginning of May 2003 (for download details, see Resources). Sync4J
has taken some time to emerge, but looks as though it has the best
prospects for a large-scale deployment of SyncML. In addition to being
a SyncML API, Sync4J also provides a SyncML server and client
tools.
Sync4J requires a J2EE environment in which to run, using Java
1.4. For those like me who don't usually live in the J2EE world,
Sync4J makes it easy by providing a JBoss installation. The
advantages of a J2EE environment are plain if that's where your
current infrastructure lies. If it isn't, then you may find the
associated resource overhead somewhat odious. However, as the
server can use the file system as its synchronization store, you
don't necessarily need to use Java code for every part of your
project.
In testing, I was unfortunately unable to get my Sony Ericsson
P800 to synchronize properly against Sync4J, although I believe
that the bug behind this is being addressed by the developers. In
fact, Sync4J has a strong support community, with separate mailing
lists for users and developers, and is funded in part by a
commercial organization, Funambol.
Summary
Pros: Professional implementation; good foundation for
a large system; Java; likely to be long-lived.
Cons: Large resource overhead; J2EE application server
required.
LibSyncML
Just in case you thought I'd not covered all the main
programming languages yet -- here's a SyncML library written in
C++. Despite the fact that development on this project is somewhat
stalled (no change since April 2002), I was quite impressed with
LibSyncML. It is a nicely assembled project, with the same
thoroughness in the construction of the distribution as you would
expect from GNU tools.
Being in its infancy, LibSyncML has little documentation. On the
other hand, it has quite a few examples. Reading through the
source, I was impressed with the clean encapsulated API that the library
presents, which was certainly a contrast to the SyncML Reference
Toolkit mentioned above. If you feel like implementing
SyncML yourself and are happy with C++ programming, I would say this is
the best project to get involved in. The author has certainly set
out in the right direction.
Summary
Pros: Straightforward
autotools-based compilation; API much cleaner than RTK.
Cons: Early stage; maintainer no longer has time to carry
on with it; C++ isn't everyone's cup of tea.
Conclusion
Open source SyncML implementation is still in an early phase.
The range of open source tools I surveyed are all unsatisfactory in
some way, though most of them represent a viable and sensible
alternative to implementing SyncML by oneself. I'm pleased to be
able to abandon my plans for a ground-up implementation of
SyncML.
So, at the end of several months' interest in SyncML, where am
I? Frankly speaking, not as far on as I'd like to be. Despite its
simple concepts, SyncML is actually quite hard to implement --
especially when compared to its predecessor in the mobile world,
IrMC synchronization. The cloud of committee-designed
specifications around mobile XML standards can be baffling, and is
often troublesome. The standard of the specifications themselves is
not to up the level one normally gets from the World Wide Web
Consortium.
In my own implementation efforts, understanding and implementing
WBXML (a binary encoding of XML) ended up diverting me from my main
goal for an unwelcome amount of time. Modern devices remove the
need for the "W*" family of specifications, and I'm glad to see them
receding.
SyncML was originally designed in a world of very low resource
devices, before the standardization of SOAP and the ready
availability of higher-bandwidth mobile Internet access. If the
protocol were to be designed today, it might well look a lot
different, and would almost certainly be easier to implement.
Definitely, some kind of SyncML-Lite that streamlines
the feature set and expectations of implementations is needed.
Resources
About the author
Rate this page
| 
