======================================================
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
http://en.wikipedia.org/wiki/Weaving
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.
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:
===========================================
http://en.opensuse.org/OpenSync
OVERALL ARCHITECTURE
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
Media
The architecture is designed to be implemented on both bluetooth and USB connections.
http://en.opensuse.org/OpenSync/SyncML-OBEX-Client
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.
http://wiki.wireshark.org/CaptureSetup/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
http://en.opensuse.org/OpenSync
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
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
~/.opensync/engines
~/.opensync/groupn
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?
syncml-http-server
-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
~/.opensync/groupn/m
where m is the next sequential number 1...n that has not previously been used for a member.
Viable group membership include:
file-sync
syncml-obex-client
nokia2evo
evo2-sync
syncml-obex-client
Configuration
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:
:q[Enter]
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:
:q[Enter]
then open the file in your favorite editor.
The file to open is:
/home/$user/.opensync/$groupnumber/$membernumber/syncmember.conf
where
$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
Testing involves giving commands and recording the results.
syncml-obex-client
http://en.opensuse.org/OpenSync/SyncML-OBEX-Client#Testcase_Basics
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 id it will ????
-b
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
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
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:
Post a Comment