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:
+ 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.
+ 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.
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.
So what alternatives exist?
bluedevil (http://www.afiestas.org/bluedevil-the-new-kde-bluetooth-stack-is-here/) 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.
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:
The architecture is designed to be implemented on both bluetooth and USB connections.
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.
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
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.
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:
-syncml syncml-obex-client Currently only Bluetooth?
-python-module Allows python plugins to be used
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:
With id it will ????
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 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:
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:
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
while others suggest
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.