Friday, March 4, 2011


Note to reader: This is now 6 March 2011. I have learned more, so am editing this post to change things that no longer are correct. If you have saved information earlier than today then please review this article.
What a day... Indeed, what a number of days...

I have spent the last several days trying to get a top down view of OpenSync.

Below is my first take, my gleanings from the zillions of postings on the subject. I will be ecstatic if someone would post comments directing me to the contrary:

Point one:

+ Everything I have found is at the warp and weft level

The postings address the finest details of the most lowly elements of the architecture, but I have not found anything that offers a top-down description of the architecture. Not even from the source...

 So as a result, there seems not to exist any source that describes in a single document on a macro level how to integrate the architecture with the remainder of the computer world. It seems to be an own-self-navel-contemplating structure in an ivory tower impervious to the forces of reality... :-(

OK, dude, here is some reality, below.

Point two:

+ Great idea, but to date, poor execution. Aside from the relevance and context issue above, there is the issue of functionality. Guess what: it is broken.

At least it is broken on OpenSuSE 11.3.

Look: here's the deal:

OpenSync is a great idea. You have a central engine that can translate from X to Y. X can be any of a zillion of different modules referred to as "plugins" that the user can choose among. Y can be any of a zillion same or different modules ("plugins") among which the user can choose.

This reminds me of the project for which I was a program manager at a large company once upon a time. Take X, translate it to a common  format (XML?) and then translate it to Y.

Great Idea.

Howevah, Poor Execution:

+ Lots of people seem to be working on the intimate details of all the possible X and Y variations.

+ But THE WHOLE SYSTEM depends on access to hardware, that is on Bluetooth and USB interfaces. And there seems to be precious little effort there.

I'm on OpenSuSE 11.3. It seems by allegation that its default Bluetooth interface (kbluetooth) for the underlying protocol stack (bluez) is broken.

However, if you upgrade KDE to 4.5.5 or install KDE 4.4.4 development files (as posted later) then you can get Bluedevil to work, so far to the extent that I can now both receive AND SEND files between laptop and Bluetooth device. The strikethrough fonts below demonstrate the deprecated remarks.
Indeed, irrespective of OpenSync I can transfer data from a remote Bluetooth device to the bluez-equipped computer using the remote device's software. But I cannot transfer data from the computer to the device, despite kbluetooth's offering to do so. It doesn't work

So what alternatives exist?

bluedevil ( is widely touted as the solution. But actually installing it is dependency hell. I have spent the entire day trying different combinations of RPMs, YMPs  (YaST Meta Packages), git streams, and tarballs. All fail in one or another way, one way in particular wiping my KDE 4.4 installation (cannot start kmserver) requiring a system reinstall ("update"). The solution appears to install devel packages for ALL of KDE, OpenSuSE, and bluedevil (libbluedevil1). So while it isn't presently easy, it is  doable.So yet another Great Idea But Poor Execution. The developers are not on the bleeding edge, they are on the hemorrhaging edge of the latest KDE variation (4.5.5) and installation techniques (CMAKE) for which little or no documentation exist.

How the heck do you use cmake anyhow? The source says just do ccmake but that crashes...


OK, next rant. If Bluetooth won't work, how about USB, hmmm?

Well, it turns out that "OpenSync does not currently support accessing the raw USB device" or words to that effect.

In other words, it doesn't work on USB.


So OK, kwitcherbichingnobodypromisedyouarosegarden, ok.

You can't make a case. It is free and open software, you get what you pay for.

But it would be nice if someone, in the course of doing the best that they can do, were to post a list of the things we are trying to do, each with an annotation of where we stand. A "todo" list so that at once:
+ A newbie can know where the project is along its trajectory
+ A supporter can see where he can apply his efforts to best solve the issue.

My contribution is in general providing the top down view posted below, and today getting my arms around the bluetooth/bluedevil part of it, contacting the developers and asking for information so I can make it better.

But we ain't there yet. The following is what I have figured out so far, I'll make it pretty tomorrow:

Opensync software comprises a main engine and "plugins".

There are two version sets: STABLE (v. 0.22 series) and UNSTABLE (v.0.39 series)

The  STABLE main engine is libopensync. The UNSTABLE main engine is libopensync1.

The STABLE plugins are libopensync-plugin-(suffix).
The UNSTABLE plugins are opensync-plugin-(suffix).
 (suffix) is, for both versions:
      Suffix        Syncs to and from
    -evolution2         Evolution
    --file              files on the computer
    -gnokii             older non-OBEX Nokia phones
    -kdepim             KDE3/4 PIMs (kontact, kaddress)
    -syncml             OBEX supporting platforms
    -python-module      Allows python plugins to be used
    -google-calendar    Google calendar
    -gpe                GPE handhelds
    -irmc               IrMC (Sony Ericsson, Siemens) handhelds
    -moto               Motorola handhelds
    -opie               Opie/OpenZaurus handhelds
    -palm               Palm devices
    -sunbird            Mozilla Sunbird calendar

The architecture is designed to be implemented on both bluetooth and USB connections.
In openSUSE 10.2 Beta 2 there is no permission for the desktop user to access the USB raw interface by default. When we receive lots of USB Products and Vendor IDs of mobile phones, from the community then we can provide a hal-resmgr fdi file which grants access to the USB RAW interface of your mobile phone.

This implies that except for testing, syncml-obex-client does not function on USB.
This page is about capturing raw USB traffic, e.g. the packets a USB mouse will generate on the Universal Serial Bus.
To dump USB traffic on Linux, you need the usbmon module. Load it with the command
      modprobe usbmon

Implementation: Sets, Groups, and Members
Implementation requires establishing a synchronization set, containing several groups. Each group contains several members.

Establishing the Set
The set is established by the existence of a group and its configuration. The set is identified by a field common to all the group and member configuration files. The most common set for Nokia devices is PC Suite

Adding Groups

Groups are created by the command
    msynctool --addgroup $groupname
    The group name can be any single alphanumeric word, e.g., nokia2evo, nokia2file, and so forth.

    Creating a group creates two subdirectories
    where n is the next sequential number 1...n that has not previously been used for a group.

Adding Members
Members are added to the group by the command
    msynctool --addmember $groupname $membername
    The member name must be the name of the function in the desired plugin:

      Plugin        Membername
    -evolution2    evo2-sync
    --file         file-sync
    -gnokii        gnokii-sync
    -kdepim        kdepim-sync
    -syncml        syncml-obex-client Currently only Bluetooth?
    -python-module Allows python plugins to be used
    -google-calendar    google-calendar-sync
    -gpe           gpe-sync
    -irmc          irmc-sync
    -moto          moto-sync
    -opie          opie-sync
    -palm          palm-sync
    -sunbird       sunbird-sync

    Adding a member creates a subdirectory
    where m is the next sequential number 1...n that has not previously been used for a member.

Viable group membership include:



For each group configure each client by invoking
     Configure client 2 syncml-obex-client:
     msynctool --configure $groupname $membernumber

    This creates the configuration file and opens it in vi.

    For  some members nothing needs to be done, so just issue the vi command:


    For other members much needs to be done but is done so much more
    easily in kate or some other GUI text editor so just quit:


    then open the file in your favorite editor.

    The file to open is:



     $user is your user name,  
     $groupnumber is the sequential number for the group, and
     $membernumber is the sequential number for the member, obtained from the -addgroup and -addmember actions described above.

Testing involves giving commands and recording the results.

        This URL discusses a number of tests. Essentially they are setting the parameters of the syncml-obex-client configuration file and testing its response. All are invoked with the following command:

        syncml-obex-client --$testtype [$test parameters]

            where $testtype [$test parameters] can be any of the following:

--sync $type $database   Set data types to be synched
--identifer $name        Set syncronization set identifier
--wbxml                  Sets use of wbxml format 
                         (WAP Binary XML instead of 
                         plain XML)
 -u             With no id it will list all available
                With id it will ????
 -b             Bluetooth configuration

         syncml-obex-client --sync $type $database

            * type: stands for the mimetype -
                  o text/x-vcard - for contacts
                  o text/x-vcalendar - for events
                  o text/plain - for notes

            * database: is the name of the database in the device which stores the entries. Known database names:
                  o contacts
                  o calendar
                  o notes
                  o tasks
                  o agenda (on some Sony Ericsson, for W800i both calendar as well as agenda work)

        hcitool is a tool for testing bluetooth connections. It currently has only one option:
            hcitool scan
                Scans for Bluetooth devices and list the name of the device and the MAC address.
                Ensure your Bluetooth is enable on your mobile phone and is discoverable.

        sdptool is a tool for exploring Bluetooth connections. It currently has only one option:
            sdptool browse
                returns the Bluetooth service of the device and their channel numbers.
                The Nokia N8 returns a very long list of available Bluetooth services. The literature
                is unclear on which channel to use. This source suggests using the channel for
                    SyncMLClient         6
                 while others suggest
                    SyncMLServer         10
                Also plausible are
                    OBEX File Transfer    7
                    OBEX PC Suite Services    8
                So further explanation or testing is required to resolve this parameter.

Next, what I've gleaned as a step-by-step installation process, assuming you can get past the USB and bluetooth issues that I'm having on OpenSuSE 11.3.

No comments: