SyncEvolution - The Missing Link

manipulate Evolution, KCalExtended/mkcal, QtContacts PIM items via uniform command line

Patrick Ohly — Tue, 31 Aug 2010 15:06:35 +0000

The current development version of SyncEvolution, the one which will become 1.1, has some new features which may be useful for command line aficionados like myself: query and manipulate items in the databases that can be accessed with SyncEvolution backends.

This is particularly useful for the new PIM storages in MeeGo, QtContacts and mkcal (formerly known as KCalExtended). Both are part of MeeGo Core, but come without any kind of frontend in Core. SyncEvolution provides a uniform way of testing these new storages using the command line or scripts.

Installation

In MeeGo, make sure that at least 1.0.99.5 rpms (required for mkcal) or better, 1.0.99.6 (for QtContacts) get installed. The core "syncevolution" rpm is needed plus "syncevolution-kcalextended" resp. "syncevolution-qtcontacts".

When compiling from source, check out the master branch of "syncevolution" and "libsynthesis" and follow the instructions in the "HACKING" document. Add --enable-kcalextended resp. --enable-qtcontacts as needed...

HOWTO

These examples illustrate how to use the new options in combination with mkcal. In 1.0.99.6, "mkcal" can be used as type instead of "kcalextended", as in the examples below. Only events are supported at the moment, todos and journal entries in the calendar are ignored.

Wipe out calendar data the hard way:

rm -f ~/.calendardb*

Import an event:

$ cat >/tmp/example.ics <<EOF
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART:20100823T170000
DTEND:20100823T173000
SUMMARY:first event
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR
EOF

$ syncevolution --import /tmp/example.ics --source-property type=kcalextended @foo bar
#0: 3f630f1d-8009-4465-907b-3ec28248b90b-rid
[ERROR] stderr: kdedate/ksystemtimezone.cpp: 313 - cannot get wall_clock_info (localzone) - QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name com.nokia.time was not provided by any .service files")

Because many of these system libraries don't expect to be used by command line users, they spew out a lot of debugging information. The SyncEvolution command line filters this output and suppresses most of it. Developers who want to see it, can set the SYNCEVOLUTION_DEBUG environment variable to 1. They should also add --daemon=no to run the operation inside the "syncevolution" process instead of the "syncevo-dbus-server".

The error in this case is MeeGo bug, which I'll strip from the output of the following examples.

The command line above works without any "@foo" configuration and "bar" data source, because the source type is specified explicitly. Configuring this value permanently makes the command line shorter:

$ syncevolution --configure --source-property type=kcalextended @default calendar

List all events:

$ syncevolution --daemon=no --print-items @default calendar
3f630f1d-8009-4465-907b-3ec28248b90b-rid: first event

Export events to stdout:

$ syncevolution --export - @default calendar 
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20100901T131100Z
DTSTAMP:20100901T130859Z
UID:a62893e3-3df1-4a92-b57b-d05c805d4078
LAST-MODIFIED:20100901T131009Z
SUMMARY:first event
DTSTART:20100823T170000
DTEND:20100823T173000
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

Export one specific event into a file (like everything else, this also works for multiple events, writing into a single file or a directory):

$ syncevolution --export /tmp/exported.ics @default calendar 3f630f1d-8009-4465-907b-3ec28248b90b-rid

Update that event, showing of reading from stdin here:

$ perl -p -e 's/first event/first event modified/' /tmp/example.ics | syncevolution --daemon=no --update - @default calendar 3f630f1d-8009-4465-907b-3ec28248b90b-rid
#0: 3f630f1d-8009-4465-907b-3ec28248b90b-rid

$ syncevolution --daemon=no --export - @default calendar | grep SUMMARY
SUMMARY:first event

Hmm, that didn't work as intended. Need to investigate... ah, I haven't reimplemented that part with the new mkcal API yet. Will be fixed in 1.0.99.6.

Delete the event:

$ syncevolution --delete-items @default calendar 3f630f1d-8009-4465-907b-3ec28248b90b-rid
[INFO] calendar: deleting "first event"

REFERENCE

$ syncevolution --help
...
List items:
  syncevolution --print-items <config> <source>
Export item(s):
  syncevolution [--delimiter <string>] --export <dir>|<file>|- <config> <source> [<luid> ...]
Add item(s):
  syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config> <source>
Update item(s)
  syncevolution --update <dir> <config> <source>
  syncevolution [--delimiter <string>|none] --update <file>|- <config> <source> <luid> ...
Remove item(s):
  syncevolution --delete-items <config> <source> <luid> ...
...
--print-items
  Shows all existing items using one line per item using
  the format "<luid>[: <short description>]". Whether the description
  is available depends on the backend and the kind of data that it
  stores.

--export
  Writes all items in the source or all items whose <luid> is
  given into a directory if the --export parameter exists and is a
  directory. The <luid> of each item is used as file name. Otherwise it
  creates a new file under that name and writes the selected items
  separated by the chosen delimiter string. stdout can be selected with
  a dash.

  The default delimiter are two newline characters for a blank line. This
  works for vCard 3.0 and iCalendar 2.0, which never contain blank lines.
  Because items may or may not end in a newline, as a special case the
  initial newline of a delimiter is skipped if the item ends in a newline.

--import
  Adds all items found in the directory or input file to the
  source.  When reading from a directory, each file is treated as one
  item. Otherwise the input is split at the chosen delimiter. "none" as
  delimiter disables splitting of the input.

--update
  Overwrites the content of existing items. When updating from a
  directory, the name of each file is taken as its luid. When updating
  from file or stdin, the number of luids given on the command line
  must match with the number of items in the input.

--delete-items
  Removes the specified items from the source. Most backends print
  some progress information about this, but besides that, no further
  output is produced. Trying to remove an item which does not exist
  typically leads to an ERROR message, but is not reflected in a
  non-zero result of the command line invocation itself because the
  situation is not reported as an error by backends (removal of
  non-existent items is not an error in SyncML).

SyncEvolution 1.0.1 released

Patrick Ohly — Sat, 17 Jul 2010 07:08:23 +0000

SyncEvolution 1.0.1

A bug fix release. The main reason for releasing it is that SyncEvolution 1.0 no longer worked on recent distros (Fedora Core 13, Debian testing) because of a name clash between the Bluez D-Bus utility code and recent glib.

Details:

compile fix for FC 13 (and possibly others): use private copy of gdbus (BMC #3556)
sync-ui: prevent overwriting device configs by accident (BMC #3566,BMC #1194) Setting up a phone used the template name as config name and overwrote an existing configuration of another phone that was created using that same template. Now the code uses the Bluetooth device name as set on the device and checks for (less likely) collisions. It also sanitizes the name to avoid complicated config names (only relevant when also using the command line).
syncevo-dbus-server: accept 'application/vnd.syncml+xml; charset=UTF-8' for starting an HTTP session (BMC #3554) The redundant charset specification was set by the Funambol Thunderbird client. Because of a literal comparison against 'application/vnd.syncml+xml' the messages were rejected.
config fix: operations on non-peer configs failed (BMC #3157) When running operations on a non-peer configuration (like --restore @default addressbook), the operation fails with [ERROR] : type 'select backend' not supported
ZYB.com: service goes away end of June 2010, template removed (BMC #3310)
some build (BMC #2586, BMC #3557) and language updates

Source, Installation, Further information

Source snapshots are in http://downloads.syncevolution.org/syncevolution/sources

i386, amd64 and lpia binaries of 1.0 for Debian-based distributions are available via the "stable" syncevolution.org repository. Add the following entry to your /apt/source.list, then install "syncevolution-evolution":

deb http://downloads.syncevolution.org/apt stable main

These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/syncevolution/evolution. In contrast to 0.8.x archives, the 1.0 .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise.

After installation, follow the getting started steps.

SyncEvolution 1.0 released

Patrick Ohly — Wed, 16 Jun 2010 15:23:19 +0000

After several betas and lot of testing, it's finally time to announce the end of the 1.0 development cycle: SyncEvolution 1.0 is released and replaces 0.9.2 as the stable version.

0.1 was released over four years ago. It has always bee part of the long-term vision to bring "personal SyncML" to desktops. Thanks to the Synthesis engine and Intel's support for the project, this goal has been reached and this release really deserves the magic 1.0 label.

For those not familiar with the project, SyncEvolution synchronizes personal information management (PIM) data like contacts, calenders, tasks, and memos using the SyncML information synchronization standard. Up to and including 0.9.2, a third-party SyncML server was required. In 1.0, SyncEvolution itself is able to act as a SyncML server, both via HTTP and Bluetooth (direct sync with phones).

SyncEvolution 1.0

Major new features compared to previous stable release:

synchronize directly with a phone over Bluetooth/OBEX
accept Bluetooth/OBEX connections in cooperation with obexd >= 0.19
run SyncEvolution as a rudimentary HTTP SyncML server

The GTK sync-UI can be used to select a paired phone and create a configuration for it based on the bundled configuration templates. Configuration templates are included for Nokia phones; for other phones see the HOWTO and check out the Wiki there. Some users have already reported success for Sony Ericsson phones and added setup instructions. New templates from the Wiki can be dropped into ~/.config/syncevolution-templates under an arbitrary file name.

Unexpected slow syncs can be detected when running as client (MB #2416) and unless turned off (see "preventSlowSync"), SyncEvolution aborts the session so that the situation can be analyzed. A refresh from client or server might be more suitable. The command line tool provides instructions at the end of its output. The GTK sync-UI points towards its recovery dialog.

Automatic synchronization is supported by the syncevo-dbus-server (MB #6378). When that is installed, it will be started as part of a user session and keep running to trigger syncs in the background. Notifications are emitted when syncs start, end or fail (MB #10000).

Automatic synchronization can be enabled separately for each peer ("autoSync=0/1", off by default), will be done at regular intervals ("autoSyncInterval=30" minutes) when online long enough ("autoSyncDelay=5" minutes). That last option ensures that a) an automatic sync does not attempt to use a network connection unless it was already active and b) hopefully is also around long enough to complete the sync.

The Synthesis XML configuration was split up into different parts which are assembled from /usr/share/syncevolution/xml. Files in ~/.config/syncevolution-xml override and extend the default files, which my be useful when adding support for a new phone.

SyncML servers:

ZYB.com now works thanks to a workaround for anchor handling (MB #2424); only contacts tested because everything else is considered legacy by ZYB.com
Horde: avoid confusing the server with a deviceId that starts like the ones used in old Funambol clients, helps with calendar sync (MB #9347)
Mobical.net (and other, similar services): fix vCalendar 1.0 alarm properties before importing them (MB #10458)
desknow.com works when switching to SyncMLVersion = 1.1
Funambol, Memotoo (and probably others): preserve meeting series when receiving update for detached recurrence (MBC #1916)

Evolution:

calendar backend: minor fix for change tracking when deleting a single instance of a recurring event
workaround for Evolution 2.30: "timezone cannot be retrieved because it doesn't exist" is triggered incorrectly when importing non-standard timezone definitions because libecal changed an error code (MB #9820)

Performance and reliability improvements (MB #7708):

synccompare much faster
database dumps consume less disk space
more intelligent about expiring obsolete session directories and backups
database accesses are reduced in several backends
shorter logs (MB #8092)
message resending helps under unreliable network connectivity ("RetryInterval")
full support for suspend&resume in SyncEvolution client to SyncEvolution or Synthesis server syncs
better handling of certain third-party time zone definitions (MBC #1332)

Improved GTK sync-UI:

revised config screen: all in one list where entries can be expanded, integrated setup of sync with other devices
recovery support: restore from backup, unexpected slow sync handling
spinner while network is in use (MB #2229)
interactive password requests (MB #6376)
uses new D-Bus API

Command line:

fixed printing of rejected items (MB #7755)
consistent logging of added/updated/deleted items with short description
improved error reporting (textual descriptions instead of plain error codes MB #2069, partial success MB #7755, record and show first ERROR encountered MB #7708)
can create new sources (MB #8424)
runs operations inside daemon and thus avoids conflicts with operations done by other clients; for testing purposes (like running a client which talks to a local server in the daemon) it is still possible to ignore the daemon (--daemon=no, MB #5043)
revised README, now also available as man page (MBC #690)

Redesigned and reimplemented D-Bus API, used by sync-UI and command line:

central syncevo-dbus-server controls configurations and sync sessions
accepts incoming SyncML connection requests and messages received by independent transport stubs (obexd, HTTP server, ...)
can be used by multiple user interfaces at once
fully documented, see src/dbus/interfaces and http://api.syncevolution.org
no longer depends on dbus-glib with hand-written glue code for C++, instead uses gdbus plus automatic C++ binding generated via C++ templates

Revised configuration layout (MB #8048):

several peer-independent sync and source properties are shared between multiple peers
they can be accessed without selecting a specific peer, by using an empty config name or with the new "@" syntax
user interface of command line unchanged
old configurations can be read and written, without causing unwanted slow syncs when moving between stable and unstable SyncEvolution versions
old configurations can be migrated with the "--migrate" command line switch; however, then older SyncEvolution can no longer access them and migrating more than one old configuration causes the second or later configuration to loose its "deviceId" property (which is shared now), causing a slow sync once
config names may contain characters that are not allowed in the file names used for the underlying files; will be replaced with underscores automatically (MB #8350)

Upgrading from 0.9.x:

Upgrading and downgrading should work seamlessly when using existing configurations.
The new configuration layout is only used when creating new configurations or explicitly invoking "syncevolution --migrate" (see above). Such configs cannot be used by older SyncEvolution releases.
The new "RetryInterval" property causes messages to be resent after 2 minutes (increased from 1 minute in previous 1.0 betas). At least the Funambol server is known to not handle this correctly in all cases. So in the Funambol config template the interval is set to zero, disabling the feature. Disabling the feature must be done manually in existing Funambol configurations.

SyncEvolution 1.0 beta 3 -> 1.0 final

Bug fixes and new features:

Configuration templates are stored in a single file (MBC #1208). New templates (like something downloaded from the Wiki can be dropped into $HOME/.config/syncevolution-templates using an arbitrary file name.
Progress and per-source status are now also reported and recorded when running in server mode (MBC #1359). There are still several limitations (sync mode not reported, no information about sent/received/processed items while the sync runs, see MBC #2786).
Better handling of certain third-party time zone definitions (MBC #1332). Better logging to track down such problems.
D-Bus server + command line: return error code when failed (MBC #2193)
syncevo-phone-config: simplified command line options, several bug fixes (syntax error, incorrect handling of calendar+todo, MBC #1197)
Revised README, now also available as man page (MBC #690). Conversion of D-Bus API documentation into .html page (MBC #1745).
Funambol, Memotoo (and probably others): preserve meeting series when receiving update for detached recurrence (MBC #1916)
Fix for potential out-of-bounds memory access (MBC #1007).
HTTP server: fix for potential crash when second session was requested while an older one was still running, initial sync was done without libical time zone information and thus may have mismatched times (MBC #2435)
Nokia E55: convert alarm times (MBC #1657). This is done via a new remote rule in /usr/share/syncevolution/xml/remoterules/server/46_E55.xml If another phone needs the same treatment, then copy that file to ~/.config/syncevolution-xml/remoterules/server and edit the element.
GTK GUI: styling fix (MBC #1372), updated toolbar for MeeGo 1.0 (MBC #1970), avoid duplicating configs when selecting a config created by syncevo-phone-config or the command line (MBC #1266), scroll bars for emergency window (MBC #1296), avoid compile problem on Fedora Core 13 due to name collision with system sync() call, updated translations.

Known Issues

Compatibility with phones has not been tested as well as compatibility with the officially supported SyncML servers. Some issues have been reported which still need to be investigated:

Nokia N85: ignores refresh-from-server? (MBC #2722)
Sony Ericsson W595: All-day-events created in evolution are synchronized as all-day-events + 1 additional day in the mobile (MBC #2093)
Nokia N81: Evolution contacts loose "Other" email-addresses when synced two-way (MBC #2566)
Nokia phones: absolute alarm time? (MBC #1657)

Call for action: test with your phone and report which config works and how well synchronization works.

Other known issues:

server progress events: no information about sync mode (MBC #2786)
Calendar event alarm synchronization between N900 and Goosync (MBC #2764)

Source, Installation, Further information

Source snapshots are in http://downloads.syncevolution.org/syncevolution/sources

deb http://downloads.syncevolution.org/apt stable main

After installation, follow the getting started steps.

Memotoo

Patrick Ohly — Sun, 25 Apr 2010 08:09:45 +0000

Server with very good support for SyncEvolution, see http://www.memotoo.com/index.php?rub=infoSyncML. It is part of SyncEvolution's nightly testing and included in the list of configuration templates that come with SyncEvolution.

SonyEricsson P1i

Patrick Ohly — Fri, 23 Apr 2010 20:30:02 +0000

| Key | Value |
|------|-----|
| Phone manufacturer | SonyEricsson|
| Phone model | P1i|
| Phone firmware version |CXC162108 R6G04 |
| Data that can be synchronized | none |
| Data that has problems | contacts,events,tasks,memos |
| SyncEvolution version | 1.0 beta 3 |
| SyncEvolution platform | Gentoo linux |
| SyncEvolution backend | Evolution/as plain files/ |
| Configuration template included in SyncEvolution: | no, syncevo-phone-config.py could not create one neither |
| Tested by | George Schreiber |

Comments:

Failed to get this phone syncing with the 1.0 beta 2 as well, it seemed like the phone bluetooth got broken (needed bluetooth restart on the phone) when tried to sync according to the wiki description, there was one similar bluetooth problem during running syncevo-phone-config, around the 1100th test (was not watching carefully as this process was running for several hours).

If trying to sync using the config that was created according to the 1.0 beta 2 wiki, it fails with these messages:

[ERROR] ObexTransport: Transport Exception in sdp_source_cb
[ERROR] ObexTransport: Transport Exception in sdp_source_cb
[ERROR] ObexTransprotAgent: Underlying transport error

Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
|               |         LOCAL         |        REMOTE         | FLI |
|        Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|   addressbook |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|      calendar |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          memo |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          todo |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          start Fri Apr 23 22:17:19 2010, duration 0:10min           |
|          external transport failure (local, status 20043)           |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: ObexTransport: Transport Exception in sdp_source_cb

the logfile (for details) ends like this (apparently where things go wrong):

     [2010-04-23 22:17:19.241] 0: integer ITEMLIMIT

     [2010-04-23 22:17:19.241] 1: integer NEEDFILTER

     [2010-04-23 22:17:19.241] 2: integer PASSES

     [2010-04-23 22:17:19.241] Resolving - processitemscript,
   ctx=0xCA8FCD8, VarDefs:

     [2010-04-23 22:17:19.241] 0: integer ITEMLIMIT

     [2010-04-23 22:17:19.241] 1: integer NEEDFILTER

     [2010-04-23 22:17:19.241] 2: integer PASSES

     [2010-04-23 22:17:19.241] 3: integer n

     [2010-04-23 22:17:19.242] SyncML server account:

     [2010-04-23 22:17:19.242] client: SyncEvolution 1.0beta3 for
   workstation

     [2010-04-23 22:17:19.242] device ID:
   syncevolution-44d23b69-c550-444f-b60f-2d453269e597

[2010-04-23 22:17:24.398] ObexTransport: Transport Exception in
   sdp_source_cb

     [2010-04-23 22:17:24.398] Server Alerted Sync init with SANFormat 12
   failed, trying with legacy format

     [2010-04-23 22:17:29.537] ObexTransport: Transport Exception in
   sdp_source_cb

     [2010-04-23 22:17:29.538] TransportException thrown at
   ObexTransportAgent.cpp:376

     [2010-04-23 22:17:29.538] ObexTransprotAgent: Underlying transport
   error

Configuration template:

=== srejbi_p1i/config.ini ===
syncURL = obex-bt://00:1E:45:E2:71:E0
username =
password =
loglevel = 6
clientAuthType = md5
#remoteIdentifier = Sony Ericsson PC Suite for Smartphones
remoteIdentifier = mRouter SockComm
PeerIsClient = 1
enableWBXML = 0
WebURL = http://www.scheduleworld.com
ConsumerReady = 0

=== srejbi_p1i/.internal.ini ===
HashCode = 3690260817
ConfigDate = 20100423T131201Z
sync = two-way
type = addressbook:text/x-vcard
uri = addressbook
=== srejbi_p1i/sources/addressbook/.internal.ini ===
sync = two-way
type = calendar:text/x-vcalendar
uri = calendar
=== srejbi_p1i/sources/calendar/.internal.ini ===
sync = two-way
type = memo
uri = memo
=== srejbi_p1i/sources/memo/.internal.ini ===
sync = two-way
type = calendar:text/x-vcalendar
uri = todo
=== srejbi_p1i/sources/todo/.internal.ini ===
# used by the Synthesis library internally; do not modify
# adminData = 

# unique integer ID, necessary for libsynthesis
# synthesisID = 0

will try to generate another config with 1.0 beta 3 and update the wiki when there are some more results...

UPDATE:

regenerated the config files using the beta 2 howto. my best guess is that the phone syncml client is buggy, the same thing happens as before:

check that phone is ok for sync:

sdptool search --bdaddr 00:1E:45:E2:71:E0 SYNCML
Searching for SYNCML on 00:1E:45:E2:71:E0 ...
Service Name: SyncMLClient
Service Description: SyncML BT client
Service RecHandle: 0x10045
Service Class ID List:
  UUID 128: 00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
  "OBEX" (0x0008)

run sync:

syncevolution srejbi_p1i
[INFO] calendar: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] Server sending SAN
[ERROR] OBEX Request 3 got a failed response Forbidden
[ERROR] ObexTransprotAgent: Underlying transport error

Synchronization failed, see /home/george/.cache/syncevolution/srejbi__p1i-2010-04-24-10-53/syncevolution-log.html for details.

Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
|               |         LOCAL         |        REMOTE         | FLI |
|        Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|   addressbook |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          start Sat Apr 24 10:53:19 2010, duration 0:03min           |
|          external transport failure (local, status 20043)           |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: OBEX Request 3 got a failed response Forbidden

log file:

Start of log - Synthesis SyncML Engine 3.4.0.6

     [-- collapse all --][++ expand all ++]

     [2010-04-24 10:53:19.458] CreateContext SyncEvolution// => 0

     [2010-04-24 10:53:19.458] Module_Capabilities:
   PLATFORM:Linux
   DLL:true
   MINVERSION:V1.0.6.0
   MANUFACTURER:SyncEvolution
   DESCRIPTION:SyncEvolution Synthesis DB Plugin
   plugin_datastore_str:no
   plugin_datastore_key:yes
   ITEM_AS_KEY:yes
   plugin_datablob:no

     [2010-04-24 10:53:19.460] Module_PluginParams
   Engine=01070000

     [2010-04-24 10:53:19.462] SyncML server account:

     [2010-04-24 10:53:19.462] client: SyncEvolution 1.0beta3 for
   workstation

     [2010-04-24 10:53:19.462] device ID:
   syncevolution-44d23b69-c550-444f-b60f-2d453269e597

     [2010-04-24 10:53:19.465] calendar: inactive

     [2010-04-24 10:53:19.467] memo: inactive

     [2010-04-24 10:53:19.469] todo: inactive

     [2010-04-24 10:53:19.478] D-Bus client :1.17332 has disconnected

     [2010-04-24 10:53:19.478] D-Bus client :1.17332 is destructing

     [2010-04-24 10:53:21.197] Connecting Bluetooth device with address
   00:1E:45:E2:71:E0 and channel 3

     [2010-04-24 10:53:21.760] OBEX progress

     [2010-04-24 10:53:21.819] OBEX Transport: get header who from connect
   response with value SYNCML-SYNC

     [2010-04-24 10:53:21.819] Server sending SAN

     [2010-04-24 10:53:21.819] ObexTransport send is called

     [2010-04-24 10:53:21.819] OBEX progress

     [2010-04-24 10:53:21.938] OBEX progress

     [2010-04-24 10:53:22.642] OBEX Request 3 got a failed response
   Forbidden

     [2010-04-24 10:53:22.643] TransportException thrown at
   ObexTransportAgent.cpp:408

     [2010-04-24 10:53:22.643] ObexTransprotAgent: Underlying transport
   error

and some "fun" (phone needs a bluetooth restart to get back to normal):

sdptool search --bdaddr 00:1E:45:E2:71:E0 SYNCML
Searching for SYNCML on 00:1E:45:E2:71:E0 ...

until a BT restart is done on the phone, further sync attempts end up like this:

[INFO] calendar: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[ERROR] ObexTransport: Transport Exception in sdp_callback_impl
[ERROR] ObexTransportAgent: Bluetooth service search failed
[ERROR] ObexTransprotAgent: Underlying transport error

Synchronization failed, see /home/george/.cache/syncevolution/srejbi__p1i-2010-04-24-10-56/syncevolution-log.html for details.

Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
|               |         LOCAL         |        REMOTE         | FLI |
|        Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|   addressbook |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          start Sat Apr 24 10:56:24 2010, duration 0:02min           |
|          external transport failure (local, status 20043)           |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: ObexTransport: Transport Exception in sdp_callback_impl

log:

Start of log - Synthesis SyncML Engine 3.4.0.6

     [-- collapse all --][++ expand all ++]

     [2010-04-24 10:56:24.184] CreateContext SyncEvolution// => 0

     [2010-04-24 10:56:24.184] Module_Capabilities:
   PLATFORM:Linux
   DLL:true
   MINVERSION:V1.0.6.0
   MANUFACTURER:SyncEvolution
   DESCRIPTION:SyncEvolution Synthesis DB Plugin
   plugin_datastore_str:no
   plugin_datastore_key:yes
   ITEM_AS_KEY:yes
   plugin_datablob:no

     [2010-04-24 10:56:24.185] Module_PluginParams
   Engine=01070000

     [2010-04-24 10:56:24.187] SyncML server account:

     [2010-04-24 10:56:24.187] client: SyncEvolution 1.0beta3 for
   workstation

     [2010-04-24 10:56:24.187] device ID:
   syncevolution-44d23b69-c550-444f-b60f-2d453269e597

     [2010-04-24 10:56:24.191] calendar: inactive

     [2010-04-24 10:56:24.193] memo: inactive

     [2010-04-24 10:56:24.193] todo: inactive

     [2010-04-24 10:56:24.203] D-Bus client :1.18023 has disconnected

     [2010-04-24 10:56:24.203] D-Bus client :1.18023 is destructing

     [2010-04-24 10:56:26.394] ObexTransport: Transport Exception in
   sdp_callback_impl

     [2010-04-24 10:56:26.394] ObexTransportAgent: Bluetooth service
   search failed

     [2010-04-24 10:56:26.395] TransportException thrown at
   ObexTransportAgent.cpp:376

     [2010-04-24 10:56:26.396] ObexTransprotAgent: Underlying transport
   error

(that looks fair enough as apparently the BT-syncml component must be crashed on the phone)

config (simplified, addressbook only, same results if playing with WBXML or remoteIdentifier):

===config.ini===
syncURL = obex-bt://00:1E:45:E2:71:E0
remoteIdentifier = PC Suite
PeerIsClient = 1
SyncMLVersion = 1.2
enableWBXML = 1
WebURL = http://www.scheduleworld.com
ConsumerReady = 1
===sources/addressbook/config.ini===
sync = two-way
type = addressbook:text/x-vcard
uri = Contact
===

Sony Ericcson K750i

Patrick Ohly — Fri, 23 Apr 2010 19:20:40 +0000

Key	Value
Phone manufacturer	Sony Ericsson
Phone model	K750i
Phone firmware version	?
Data that can be synchronized	contacts, events, tasks, memos
Data that has problems
SyncEvolution version	1.0 beta 3
SyncEvolution platform	Linux desktop
SyncEvolution backend	plain files in syncevo-phone-config
Configuration template included in SyncEvolution:	no
Tested by	Patrick Ohly

Comments:

Only tested with "syncevo-phone-config --advanced". In other words, at least simple items could be copied to and from the phone.

Configuration template:

=== template.ini ===
fingerprint = <Model> <Manufacturer>
=== config.ini ===
SyncMLVersion = 1.1
peerIsClient = 1
remoteIdentifier = PC Suite
=== sources/addressbook/config.ini ===
type = addressbook:text/vcard
sync = two-way
uri = Contact
=== sources/calendar/config.ini ===
type = calendar:text/x-vcalendar
sync = two-way
uri = Calendar
=== sources/todo/config.ini ===
type = todo:text/x-vcalendar
sync = two-way
uri = Task
=== sources/memo/config.ini ===
type = memo:text/plain
sync = two-way
uri = Memo

eGroupware

Patrick Ohly — Wed, 21 Apr 2010 13:56:47 +0000

Contributed on 10.09.2006 by Mathias Weyland, who also graciously provided access to a server for testing for a while. Not currently tested.

SyncEvolution can handle synchronization with eGroupware (eGW), starting with 0.4-pre2 plus one patch, which was included in 0.4.

Make sure eGW fits the needs for correct operation with syncML, in particular php5 and Pear::Log. See here for information about requirements and settings.

The SyncEvolution setup is rather straightforward. Although the SyncML code of eGW is based on horde (see above), there's no need to restrict authentication to auth-basic.

Set syncURL to http:////rpc.php. Set "type = text/calendar" and "uri = ./calendar" for the calendar and "type = text/x-vcard" and "uri = ./contacts", respectively for the address book.

Warning: "uri = ./calendar" apparently is the official uri, but several users reported that with that setting events created in eGW were not copied into Evolution while "uri = calendar" worked alright. Until this is clarified, the recommendation is to use "uri = calendar".

All in all, synchronization is working well, but I'd like to mention some things I noticed not to work:

Recurring events don't stop at a final date in eGW, even when this final date has been set in evolution.
"A known issue of old Evolution versions." -- Patrick
Recurrence exceptions are not respected.
"eGW seems to rely on storing the remaining instances of an event, but does not include this information in the data it sends to SyncEvolution. On the other hand, SyncEvolution also does not yet support this either. Exceptions defined in Evolution's dialog are stored as simple properties and are sent to the server, but eGW does not seem to use that information."
New appointments in eGW are not sync'ed to evolutions. But updates are.
"Could not reproduce. If it still occurs, please submit a bug report."
With SyncEvolution 0.6, Ioannis Ioannou had a problem with lost or messed up telephones. Part of the problem was in SyncEvolution (it did not correctly detect types as sent by eGW, fixed in 0.7), part of the problem was in eGW (it does not handle the vCards sent by SyncEvolution correctly). Ioannis found out that eGW has hard-coded mappings for incoming data, which might have to be adapted on a case-by-case basis for clients. He submitted a patch (thanks!) which adds a SyncEvolution mapping to eGW. Hopefully this problem will be fixed. The original version of his patch changes class.vcaladdressbook.inc.php in egroupware/addressbook/inc and was tested on 1.4.001, 1.4.002, and the trunk of 2007-09-25th.
If communication with eGW stops with a Server Failure: server returned error code -1 error, then the reason is most likely a parser problem in eGW. Some information about this can also be found in the same discussion thread.

Horde

Patrick Ohly — Wed, 21 Apr 2010 13:54:54 +0000

Contributed on 08.05.2006 by Todd Pytel based on an early 0.4 CVS snapshot.

The Horde framework includes a SyncML component compatible with SyncEvolution and other SyncML clients. This component is built in to the core framework and does not need to be separately installed. For synchronization to work, you need to do a few things....

Use fresh Horde sources: Many SyncML changes are applied only to Horde's CVS HEAD branch. The stable branch does include some SyncML support, but it's not as complete as what's found in CVS HEAD. If you really don't want to use CVS HEAD sources entirely, you might be able to get away with updating just the files /horde/rpc.php and /horde/turba/lib/api.php. Try the versions from the stable CVS branch first before trying HEAD, and don't complain if they don't work correctly on top of a release installation. Much better to just use CVS HEAD altogether.
Configure authentication: On the Horde server, the only thing that might require configuration is authentication. By default, SyncEvolution will use md5 authentication, which is nice when you're using HTTP rather than HTTPS. Support for md5 was very recently added to Horde, and will almost certainly have changed by the time you read this. At the moment, see the comments in SyncML/Backend.php around line 404 for details. Alternatively (and more easily), run SyncML over HTTPS and tell SyncEvolution to use basic, non-md5 authentication, by adding
clientAuthType = syncml:auth-basic serverAuthType = syncml:auth-basic

to the ~/.sync4j/evolution/horde/spds/syncml/config.txt file (see below).
Configure SyncEvolution: Read the generic SyncEvolution docs, then come back here. Copy one of the prepackaged configuration directories (like etc/scheduleworld_1) to ~/.sync4j/evolution/horde as a starting point. It doesn't matter much which template directory you use. They're not very different, and there's not much to configure. You need to modify (or create) the following items. In ~/.sync4j/evolution/horde/spds/syncml/config.txt:
syncURL = https://your.horde.site.com/horde/rpc.php

Adjust http/https appropriately and make sure the address matches the webroot configuration on the server.

deviceId = sc-api-nat-<identifier>

Each computer/username combo that syncs should have a different identifier, for example, using an identifier like "home-myusername" makes sense. The username and password lines should match your Horde username and password. Add the AuthType lines from #2, if you don't want md5 authentication. Next, decide which Evolution databases you want to synchronize. I use only the addressbook, but the others should be similar. In ~/.sync4j/evolution/horde/spds/sources/addressbook_1/config.txt set

uri = contacts

That's it. The other components use "calendar" (Kronolith), "notes" (Mnemo), and "tasks" (Nag). If you don't want to synchronize a particular database, be sure to set "sync = none" in its config file.
Try it out:
syncevolution horde

If you get errors, check out the Horde Sync wiki for more information on debugging. The sync@lists.horde.org mailing list is also very useful. Check the archives there, to see if there's any info about your problem.

Enhancement (Note: This may be unnecessary when Turba 3 is released.)

The default configuration for Turba (Horde's address book component) is less than ideal for SyncML, because the turba_objects database table is somewhat oversimplified (for example, all components of an address are combined in a single field). This leads to vcards that are missing some fields when they're synced between Horde and Evolution. Fortunately, Turba is very clever, when it comes to reading its database, and can automagically adjust to many nondefault configurations. If you're creating a fresh Turba installation, you can improve its SyncML capabilities greatly by using this custom sources.php file. If you do this, then you'll also need to make sure the appropriate fields are available in the turba_objects table in your database. Using this postgres script, instead of the one included with Horde, will create an appropriate turba_objects from scratch. For MySQL, there is no such script available, so make the changes manually. Nothing else needs to be done with Turba, apart from using the custom sources.php and creating an appropriate turba_objects table. The Turba code will automatically recognize the new fields and use them correctly in SyncML transactions. Thanks to Karsten Fourmont for providing this solution.

Synthesis

Patrick Ohly — Wed, 21 Apr 2010 13:54:02 +0000

The Synthesis server is a very configurable server which stores its data in a database. Contact data can be exchanged in vCard 2.1 and 3.0 format when using the default configuration, but due to how it is stored, several attributes used by Evolution get lost or modified. It might be possible to protect against loss of those attributes, by tuning the Synthesis server setup. More work would also be required to exchange calendar entries and tasks, because in the default configuration they are not accepted in the iCalendar 2.0 format of Evolution.

Ovi

Patrick Ohly — Wed, 21 Apr 2010 13:52:24 +0000

OVI.com is Nokia's set of web services, including among them complete PIM data handling and synchronization with phones via SyncML. Formal interoperability testing has not been done yet, but a user of SyncEvolution 0.9.1 reports that it works for him. Getting the necessary setting information for SyncEvolution is a bit tricky, so check out his nice report for a step-by-step guide.