Re: [SyncEvolution] syncevolution and a radicale caldev server
by Patrick Ohly
On Fri, 2012-02-17 at 15:14 +0100, Gregor Horvath wrote:
> Am Fri, 17 Feb 2012 11:12:52 +0100
> schrieb Patrick Ohly <patrick.ohly(a)intel.com>:
>
> > On Tue, 2012-02-14 at 15:57 +0100, Patrick Ohly wrote:
> > > But as Radicale is an example where multiple databases are possible
> > > (in
> > > contrast to Google), it's worth spelling out explicitly how such a
> > > config can be created:
> >
> > [...]
> >
> > William, did this work?
> >
> > Perhaps you (or someone else) has the time to turn the instructions
> > into a proper HOWTO? I created a place holder Wiki page for it here:
> > http://syncevolution.org/wiki/synchronizing-radicale
> >
> >
William sent me some debug logs, but then ran out of time. So I've
installed Radicale myself and found an issue that'll break
SyncEvolution: items reported by the server include double slashes in
the path.
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<response>
<href>/public_user/calendar/calendar_1//1234567890(a)dummy.ics</href>
^^
SyncEvolution will then use /1234567890(a)dummy.ics as path in future
requests, which Radicale rejects with either 404 or 401 errors.
I'll work around that in SyncEvolution. I'm not sure whether there is a
solution with 1.2.2.
Have you considered Calypso (http://keithp.com/blogs/calypso/)? I don't
know yet whether it works with SyncEvolution; if there is interest, then
I will try it.
> I am trying to do the same thing (with one calender to start with)
> N900 <-> radicale but it did not work, because it seems the Maemo
> calendar is not found:
>
> http://pastebin.com/huMXDsEx
>
> What I am doing wrong?
You have additional spaces after your \ character. The slash must be at
the end of each line.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4 years, 11 months
[SyncEvolution] SyncEvolution 1.3 released, hosting at freedesktop.org
by Patrick Ohly
Hello all!
After almost three months of public beta testing the next major
version of SyncEvolution is ready for release. The pre-releases did
have the desired effect of flushing out bugs not found by nightly
testing alone. Thanks everyone for packaging, downloading and testing
them!
Project status
==============
SyncEvolution synchronizes personal information management (PIM) data
via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs
contacts, appointments, tasks and memos. It syncs to web services or to
SyncML-capable phones via Bluetooth.
Binaries are available for Linux desktops (using GNOME Evolution, or
KDE's Akonadi), for MeeGo and for Maemo (Nokia N900, N9).
The project moved its bug tracking from bugs.meego.com to
bugs.freedesktop.org. All the old issues were migrated.
Please file new issues here:
http://bugs.freedesktop.org/enter_bug.cgi?product=SyncEvolution
The git repositories were also moved to freedesktop.org:
http://cgit.freedesktop.org/SyncEvolution/
SyncEvolution 1.3
=================
New features are KDE/Akonadi and ActiveSync support, not only in the
source code but also in syncevolution.org binaries. ActiveSync is the
recommended way of synchronizing contacts with Google:
https://syncevolution.org/wiki/google-contacts-activesync
The D-Bus server and local sync were rewritten considerably, to make
the code cleaner and more robust. The CalDAV backend now also supports
tasks and memos. CalDAV and CardDAV can be used in combination with a
SyncML peer ("bridging SyncML and WebDAV"), thus allowing a device
which only supports SyncML to talk to a WebDAV service without any
intermediate storage.
1.3 contains bug fixes that were not backported to 1.2.x, so upgrading
is recommended. For example, SyncEvolution 1.3 is required for
Evolution 3.4, otherwise photos are not exported properly. Support for
Evolution >= 3.6 is in the source code, but not in syncevolution.org
binaries. Further workarounds for recent changes in Google CalDAV and
Funambol One Media were added.
Upgrading from release 1.2.x
----------------------------
The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
syncevolution --configure \
syncFormat=text/x-vcard \
mobical addressbook
The Funambol template explicitly enables usage of the
"refresh-from-server" sync mode to avoid getting throttled with 417
'retry later' errors. The same must be added to existing configs
manually:
syncevolution --configure \
enableRefreshSync=TRUE \
funambol
Upgrading from releases before 1.2
----------------------------------
Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. Releases >= 1.2
automatically migrates configurations. The old configurations
will still be available (see "syncevolution --print-configs") but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.
Changes 1.2.2 -> 1.3
====================
* ActiveSync: updated to work with latest activesyncd and Google, package binaries
Syncing Google contacts was added to the nightly testing. Syncing
contacts and events with Exchange 2012 was already working. Setup
instructions and known issues are described here:
https://syncevolution.org/wiki/google-contacts-activesync
* phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744)
When deleting an item on phone and locally, the next sync failed with
ERROR messages about "object not found". This has several reasons:
- libsynthesis super data store attempts to read items
which may or may not exist (triggers ERROR message)
- it checks for 404 but Evolution backends only return a generic
database error (causes sync to fail)
* phone sync: get phone vendor and model from Device ID profile (BMC #736)
In the past we have relied on the user-modifiable device name to be
the fingerprint for matching a phone to a template which is unreliable.
This release changes this in the cases where the phone supports the
Device ID profile (DIP). If support for DIP is detected, then we
extract the vendor and product ids and attempt to associate them
with a product and vendor name by using a newly added lookup table.
This lookup table has to be maintained manually and depends on
contributions by users to cover more devices. See
http://blixtra.org/blog/2011/09/22/syncevolution-needs-you-or-at-least-yo...
* vCalendar 1.0: fixed recurring all-day event support
vCalendar 1.0 cannot represent all-day events. The workarounds for
mapping iCalendar 2.0 all-day events into vCalendar 1.0 was
incomplete, leading to effects like shifting EXDATEs and end
times.
* Funambol: ignore UID
Funambol's OneMedia sends UID, but not RECURRENCE-ID. That becomes a
problem when multiple events of the same event series are added to a
backend which follows the iCalendar 2.0 standard (CalDAV, EDS, KDE),
because these events all look like the master event, and there can be
only one of those.
SyncEvolution now strips the UID from all events coming from any
Funambol server (regardless of the version). If a future Funambol
server release adds support for both UID and RECURRENCE-ID, then
SyncEvolution will have to be updated to take advantage of the
improved server. Because the RECURRENCE-ID is also getting
stripped (despite not being set at the moment), SyncEvolution should
continue to work as it does now even if the server changes.
It would have been nice to limit this workaround to affected Funambol
server versions, but an inquiry on the Funambol mailing list didn't
get a reply, therefore SyncEvolution is playing it safe and assumes
that all future Funambol releases will have the same problem.
* Funambol: work around PHOTO TYPE=image/jpeg
A combination of Funambol Android and Funambol server recently led to
the Funambol server sending PHOTO data with TYPE=image/jpeg. This is
invalid and caused EDS to reject the photo (Vladimir Elisseev,
"[SyncEvolution] issues with syncing photos").
Work around the problem by only keeping the part of the type after the
last slash, if there is any. For image/jpeg and similar types that
leads to the desired value and does not affect valid values, because
those do not contain a slash
(http://www.iana.org/assignments/media-types/image/index.html).
* Funambol: avoid slow syncs in refresh from server
libsynthesis has traditionally implemented "refresh-from-server" as
"delete local data" plus "slow" sync. This is more compatible, because
some servers (like Google) do not support "refresh-from-server".
But it has the downside that the server cannot know that the client
won't send any data, and Funambol's OneMedia now only allows one slow
sync before blocking the next one for a certain period of time. This is
done to prevent excessive resource usage by badly behaving clients.
To accomodate both kinds of servers, the new "enableRefreshSync"
sync property can be set set to explicitly allow the usage of
the "refresh-from-server" sync mode. It's off by default. The Funambol
template has it turned on, existing configs must be updated manually
(see upgrading comments below).
* Mobical (aka Everdroid): stopped testing memo syncing
Memos used to work, but now only trigger an unspecific 400 error
on the server side.
* GTK-UI: accept service config with a username again (BMC#23106)
Suppressing configs with empty username had undesired side effects:
modifying configs for direct syncing with a device incorrectly
triggered the same error message, without any means of entering
a username. The faulty check was removed without replacement.
* GTK-UI: added GTK 3 version of UI
When GTK 3 is found during compilation, a GTK 3 version of the
UI is built. The source code of both is different to avoid
excessive use of ifdefs. At the moment, both versions offer
the same features. In the long run, the GTK 3 version will
replace the GTK 2 version.
* command line: added refresh/one-way-from-local/remote (BMC #23537)
The -from-client/server sync modes are confusing because the direction
of the data exchange depends on which side acts as SyncML server or
client.
This release introduces new modes which use -from-local/remote
instead. The statistics and messages also use these variants
now. The old modes are still understood, but are declared as "not
recommended" in the documentation.
* command line: config and source names are optional (BMC #23783)
The need to add "foo" and "bar" pseudo config and source names to the
command line even when all parameters for the operation where
explicitly specified on the command line was confusing.
Now it is possible to invoke item operations without the config and
source name. Names which refer to non-existent configs are still
accepted, as in previous releases. Typos are handled better by
producing a detailed error report which includes (as applicable):
- config doesn't exist
- source doesn't exist or not selected
- backend property not set
Because luids used to be positional arguments after <config> and
<source>, a new --luids keyword is necessary to indicate that the
ensuing parameters are luids and not <config> and <source>.
* command line: introduced --print-databases, supported for CalDAV/CardDAV
Listing databases is now a dedicated operation, instead of being done
whenever syncevolution was invoked without parameters.
Advantages:
- can be combined with property assignments for backends
which do not work without that additional information, for example
CalDAV/CardDAV:
syncevolution --print-databases \
backend=[caldav|carddav] \
syncURL=... \
username=... \
password=...
- can be done for configured sources
* command line: use both stdout and stderr
Traditionally, the "syncevolution" command line tool mixed its
INFO/ERROR/DEBUG messages into the normal stdout. This has the major
drawback that error messages get lost during operations like
syncevolution --export - @default addressbook | grep "John Doe"
Now anything which is not the expected result of the operation is
always sent to stderr. Obviously this includes ERROR messages. INFO
and DEBUG are harder to decide. Because they usually convey meta
information about the running operation, they are also sent to
stderr. The output of running a sync goes to both stdout (summary)
and stderr (progress).
* command line: allow setting empty properties
Due to the way how properties were handled internally, it wasn't
possible to explicitly set a property to its default value. Instead
the property was unset. For example, explicitly setting database= was
not possible.
This is necessary for client-test and ActiveSync, because client-test
needs to know that the testing is expected to run with the default
databases (something which normally is avoided by overwriting empty
database properties).
Now the "is set" state is tracked explicitly in the config storage and
command line property APIs. Unsetting a property via the command line
could be implemented with an explicit command line option, but is not
supported at the moment.
* command line: fixed --export <file name>
When exporting items into a file, the delimiter between items
was missing.
* command line + local sync: fixed erroneous "Comparison impossible" output.
"Comparison impossible" was incorrectly printed after a successful
comparison on the target side of local sync.
* local sync: fix timeout with local sync with libdbus
When using libdbus instead of GIO D-Bus (as done by syncevolution.org
binaries and SyncEvolution on Maemo), local sync may have aborted
after 25 seconds when syncing many items with a D-Bus timeout error:
[ERROR] sending message to child failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible ca
Reported by Toke Høiland-Jørgensen for Harmattan. Somehow not encountered
elsewhere.
* synccompare: shorter data dump of PHOTO
A full comparison of the base64 PHOTO data can be very long.
Now some key characteristics of the PHOTO data (number of
characters in base64 encoding, number of bytes in decoded
data, md5sum of decoded data) are printed instead.
That way, unintended changes of the data (different encoding,
different content) should still be found while testing and
added/removed photos are nicely visible in synccompare diffs.
* synccompare: fixed output for byte-identical duplicates
If database dumps contained byte-identical duplicates, they
were treated as a single item on the left side of a comparison.
This caused erroneous "added" entries on the right side.
* secure password storage: usage of GNOME Keyring vs. KDE KWallet configurable
Automatically detecting KDE users is not possible at the
moment. Instead KDE users have to manually set the new "keyring"
global config property to "KDE" (case insensitive) if the
SyncEvolution installation supports both, because GNOME Keyring is the
default to avoid surprises for traditional users. If only KWallet
support is enabled, then this is not necessary.
"GNOME" and "true/false/1/0/yes/no" can also be set. This has the
advantage that keyring usage can be enabled permanently for the
command line in --daemon=no mode; normally keyrings are not used in
that mode because accessing them can bring up UI dialogs.
It also becomes possible to disable keyring usage in syncevo-dbus-server,
something which couldn't be done before.
The --keyring command line option is still supported, as an alias for
"[--sync-property] keyring=<value>". The default value for --keyring
is true, to match the traditional behavior. In contrast to other sync
properties, setting "keyring" does not require an explicit --run
parameter. Again this is done to mirror traditional usage.
* config: improved 'maxlogdirs' documentation
The old explanation made it sound like nothing would get deleted by
default ("If set, ..."). That's not correct, by default only 10
sessions are kept.
Also explain the behavior of deleting intermediate sessions first.
* Evolution: always create databases (PTCOM-113)
Always try to create address book or calendar database, because even
if there is a source there's no guarantee that the actual database
was created already; the original logic for only setting this when
explicitly requesting a new database therefore failed in some cases.
This problem affected users who had never created anything locally
and wanted to use SyncEvolution to migrate their data. Now that
works without having to create dummy entries first.
* Evolution contacts: changed default sync format to vCard 3.0
vCard 3.0 is the better default because it has saner encoding
rules and defines more properties, thus avoiding the need for
non-standard extensions. However, Mobical has problems with
the new default. See upgrade instructions below.
* Evolution: added support for EDS 3.5.x
When compiled against EDS 3.5.x or later, SyncEvolution now uses
the backend code originally written for the EClient API introduced
in EDS 3.2. That code was changed so that it works with the new
include file rules and ESourceRegistry in EDS 3.5.x. Support
for using the EClient API with EDS 3.4 was removed because maintaining
three different flavors of the EDS backend code would be too much
work and not gain much (just the possibility to test the EDSClient
code with 3.4).
At the moment, this is a compile time choice made automatically
by configure. syncevolution.org binaries are compiled against
an older EDS and thus do not work with EDS 3.5.x or later.
EDS 3.5.x handles authentication itself, using a standard system
prompt if necessary. SyncEvolution can no longer provide the password,
and thus the "databaseUser/Password" options have no effect when using
EDS 3.5.x.
* D-Bus server: fixed HTTP presence for recent libdbus
Testing with libdbus 1.6.0 on Debian Testing failed because the lib
changed some behavior: instead of looking up the owner of a certain
bus name immediately, it now does that when invoking a
method. Therefore the check for "have connection" in SyncEvolution
was too simplistic and missed the fact that both were not usable,
causing the server to assume that HTTP was down while in reality it
should have assumed it to be up. This prevented auto-syncing and
manually clicking "Sync" in the GTK UI.
* D-Bus server: made notification verbosity configurable with "notifyLevel"
The new "notifyLevel" per-peer configuration option allows users to
control how many desktop notifications the D-Bus server produces while
executing an automatic sync:
0 - suppress all notifications
1 - show only errors
2 - show information about changes and errors (in practice currently the same as level 3)
3 - show all notifications, including starting a sync (default)
* WebDAV: fixed data corruption issue when uploading item with long UID
In some cases data with a very long UID wasn't handled correctly,
causing the out-going data to be malformed and probably causing a
rejection by the server. The root cause is incorrect string handling.
In releases before 1.2.99.1, only the --import operation of contacts
into CardDAV were affected. In 1.2.99.1, the same code also got used
for calendar items and then could also affect syncing.
* CalDAV: updated Google workarounds
Google started sending empty items (VCALENDAR with no VEVENT inside)
which cannot be removed. SyncEvolution 1.3 ignores such items.
The workaround for a 404 from Google Calendar for a GET (sending a
REPORT request matching the item's UID) was broken: first, processing
the result ended up calling the unset responseEnd boost function
pointer, which caused the request to fail. Second, getting multiple
items wasn't handled (data from all items concatenated together was
used).
That can happen in the somewhat unlike case that some items have a UID
which is a complete superset of the requested UID - not realistic in
real life, but happens during testing.
* Google Calendar: updated URL redirect handling
Google Calendar sometimes returns redirect requests to human-readable
web sites (an "unavailable" page, a login form). This is of course
bogus when the client is an automated CalDAV client.
The "unavailable.html" case was already handled. Made it a bit more
flexible to also catch possible variations of it (additional
parameters, https instead of http).
Added the https://accounts.google.com/ServiceLogin case. Not sure
whether retrying will help in that case, but there's not much else
that SyncEvolution can do.
* WebDAV: bridge with SyncML
Now a peer accessed via SyncML can read/write data stored in a
CalDAV/CardDAV server directly. This can be used to connect a device
which only supports SyncML to a CalDAV/CardDAV server, or sync data
between a SyncML server and a CalDAV/CardDAV server. See "CalDAV and
CardDAV" in the README for details.
* WebDAV: improved --configure
Added INFO output about checking sources. This helps with WebDAV when
the server cannot be contacted (dead, misconfigured) because otherwise
there would be no indication at all why the --configure operation
seems to hang.
Here is some example output, including aborting:
$ syncevolution --configure --template webdav \
syncURL=http://192.168.1.100:9000/ \
username=foo password=bar retryDuration=2s \
target-config@webdav-temp
[INFO] creating configuration target-config@webdav-temp
[INFO] addressbook: looking for databases...
[INFO] addressbook: no database to synchronize
[INFO] calendar: looking for databases...
[INFO] calendar: no database to synchronize
[INFO] memo: looking for databases...
[INFO] memo: no database to synchronize
[INFO] todo: looking for databases...
[INFO] todo: no database to synchronize
It timed out fairly quickly here because of the retryDuration=2s. That
also gets placed in the resulting config, which is probably not desired.
Aborting the operation is now supported:
$ syncevolution --configure \
--template webdav \
syncURL=http://192.168.1.100:9000/ \
username=foo password=bar \
target-config@webdav-temp
[INFO] creating configuration target-config@webdav-temp
[INFO] addressbook: looking for databases...
^C[INFO] Asking to suspend...
[INFO] Press CTRL-C again quickly (within 2s) to stop immediately (can cause problems in the future!)
^C[INFO] Aborting immediately ...
[ERROR] error code from SyncEvolution aborted on behalf of user (local, status 20017): aborting as requested by user
It would be good to make the CTRL-C handling code aware that it can
abort immediately instead of doing the intermediate "asking to suspend"
step, which only makes sense for sync sessions.
* WebDAV: support tasks and memos (BMC #24893)
The new backend property values "CalDAVTodo" and "CalDAVJournal"
select tasks resp. memos stored in a CalDAV collection. "CalDAV"
continues to select events.
Events, tasks and journals can be mixed in the same resource (=
URL). However, this is less efficient than storing them separately.
A good CalDAV server allows filtering items by type, and SyncEvolution
uses that. However, it was found that Radicale 0.7 ignores this
filtering, which could have led to data loss (SyncEvolution asks for
all VTODOs in preparation for a "delete all items" operation in a
"CalDAVTodo" source, gets also VJOURNALs, then deletes them).
Therefore SyncEvolution plays it safe and downloads the VTODO and
VJOURNAL data to double-check that it is working on the right items.
This causes additional traffic for well-behaving servers; currently
it cannot be turned off.
Tasks are exchanged as vCalendar 1.0 or iCalendar 2.0 VJOURNAL.
Memos are exchanged as VTODO or plain text. The logic for storing
incoming plain text is slightly different compared to the way how
the EDS memo backend did it: instead of copying the first line
from the text into the summary, it is now moved. In other words,
the first line gets stripped. The change is primarily technically
motivated; both approaches have pros and cons.
* WebDAV: improved Radicale support
Radicale > 0.7 will return status 200 for delete requests;
is now treated like 204 by SyncEvolution. 412 'Preconditiona Failed'
when asking to delete an already removed item is treated like
the more common 404 'not found'. Same with 410 'gone' instead
of 404 when trying to read a non-existent item.
* CalDAV/CardDAV sync: improved target side output
Added a "target side of local sync ready" INFO message to introduce
the output which has the target context in the [INFO] tag. The sync report
from the target side now has the target context embedded in brackets
after the "Changes applied during synchronization" header, to avoid
ambiguities.
Sometimes the backend has to resend requests because of temporary
issues. If the problem turned out to be permanent, there was a long
period of time, retryDuration=5 minutes to be precice, in which no
visible progress happened.
Now SyncEvolution's WebDAV backend will print a message like this
before going to sleep until it is time to retry:
[INFO @googlecalendar] operation temporarily (?) failed, going to retry in 5.0s before giving up in 18.4s: PROPFIND: Neon error code 1: 401 Unauthorized
The uncertainty comes from several factors. In this example, the 401
might indicate a permanent problem (wrong credentials), or it could be
Google reporting a temporary authorization problem which is (probably)
meant to slow down the client while it asks the user to re-enter the
password. SyncEvolution only asks for passwords once, so it tries
again with the same password if it was successful with it in the
past. Otherwise it gives up immediately.
Another dubious example are name server lookup errors. They can be
permanent (wrong host name) or temporary (name server
down). SyncEvolution errs on the side of retrying, to avoid
interrupting an operation which still has a chance to continue.
Output from the target side of a local sync was passed through stderr
redirection as chunks of text to the frontends. This had several
drawbacks:
- forwarding only happened when the local sync parent was processing
the output redirection, which (due to limitations of the implementation)
only happens when it needs to print something itself
- debug messages were not forwarded
- message boundaries might have been lost
In particular the new INFO messages are relevant while the sync runs
and need to be shown immediately.
* WebDAV: --status for WebDAV source aborted
The command line --status operation did not complete when applied to a
CalDAV/CardDAV source. Instead it aborted because the operation took a
code path where the backend was not fully initialized.
* file backend: more flexible sync support for memos
The databaseFormat=text/calendar for memos did not support
synchronizing as plain text. When using the new
databaseFormat=text/calendar+plain, vCalendar/iCalendar/plain text
are all valid sync formats; the storage is iCalendar 2.0
VJOURNAL in all cases.
* WebDAV: avoid potential crash during database detection
When a server responds to a PROPFIND for a path with results for some
other path, then SyncEvolution crashed during the search for the
default calendar or address book because of a bug in the code which
was meant to handle that kind of response. Apparently Yahoo Calendar
did that. Now seen again in combination with Radicale 0.6.4.
In general, the code was made more robust to cope with bugs in
Radicale 0.6.4. Later Radicale versions fixed these issues and also
worked with SyncEvolution 1.2.2 without client-side workarounds.
* WebDAV: better path normalization
"syncURL" and "database" properties had to end in a trailing slash,
otherwise items were not found (404 errors). Now the necessary slash
is added automatically.
* Curl transport: support SSLServerCertificates=<path>
When the setting refers to a directory, then CURLOPT_CAINFO doesn't
work (must be a file). Check this and use CURLOPT_CAPATH instead.
Caveat: there are some comments in the API documentation about "NSS
enabled libcurl" which supports a directory in
CURLOPT_CAINFO. Hopefully providing an explicit path in CURLOPT_CAPATH
also works in that configuration.
* code cleanup + rewrite: syncing done in separate process
syncevo-dbus-server now runs syncing in a separate process. Local
sync also uses a second helper process. This makes the D-Bus server
more responsive via D-Bus (no more blocking operations) and
minimizes the effect of bugs in code involved with syncing
(backends, system libraries, etc.).
In the long term this restructuring will also allow more advanced
features, like monitoring local or remote storage for changes.
* SyncEvolution <-> SyncEvolution sync: multiple cycles per session
SyncML only allows one send/receive cycle per session. There are cases
(for example, client side merges data that a dumber server failed to
match correctly) where client and server are still out of sync at
the end of a cycle. When SyncEvolution syncs with another SyncEvolution
instance (locally or remotely), both sides detect that the peer
can continue syncing in the same session and start over automatically
when needed. Previously the user had to start another sync session manually.
To the user this is shown as "number of cycles" in a sync session
in the sync report. "Restart" is the process of entering a new cycle.
The cycles are also visible in the command line output as multiple
INFO lines:
[INFO] eds_contact: starting first time sync from client (peer is server)
[INFO] creating complete data backup of source eds_contact before sync (enabled with dumpData and needed for prin
Local data changes to be applied during synchronization:
*** eds_contact ***
no changes
[INFO] eds_contact: sent 1/1
[INFO] eds_contact: started
[INFO] eds_contact: first time sync done successfully
[INFO] eds_contact: starting normal sync from client (peer is server) <===
[INFO] eds_contact: started <===
[INFO] eds_contact: normal sync done successfully <===
[INFO] creating complete data backup after sync (enabled with dumpData and needed for printChanges)
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| eds_contact | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
| refresh-from-local, 2 cycles, 0 KB sent by client, 0 KB received |
^^^^^^^^
| item(s) in database backup: 1 before sync, 1 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Tue Feb 7 17:07:49 2012, duration 0:03min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
* SyncEvolution <-> SyncEvolution sync: negotiate UID support via SyncCap (BMC #22783)
The semantic of UID/RECURRENCE-ID in calendar data is now tracked
per data store involved in a sync. If full iCalendar 2.0 semantic
(= IDs are globally unique) is guaranteed, then pairs are found
based on these IDs. Otherwise pairs must be found by looking at
item attributes.
Previously a hack was used to detect this kind of support (any kind
of SyncEvolution instance was assumed to support it, although some
backends do not).
* engine: add DTSTAMP+LAST-MODIFIED before writing calendar items
When writing calendar items into a backend storage as iCalendar 2.0 or
vCalendar 1.0, they should have DTSTAMP and LAST-MODIFIED values. DTSTAMP
is expected by some CalDAV servers (like Apple). LAST-MODIFIED is usually
added by the storage, but not always.
In the text/plain -> syncevolution -> text/calendar -> Radicale -> EDS
-> syncevolution chain the LAST-MODIFIED was not added by Radicale, which caused
problems for change tracking in an EDS-based SyncEvolution.
Also necessary when importing from a phone using vCalendar without
DTSTAMP directly into CalDAV.
* autotools: ensure that link lines are complete
As mentioned by Tino Keitel on the mailing list, some libs and
executables were only implicitly linked against libraries that they
called directly. This happened to work by chance because these libraries
ended up in the running executable anyway, due to indirect loading.
Now there is a "make installcheck" test for this kind of defect
and the makefiles were updated to avoid it.
One exception is libsmltk, which depends on the caller providing
SySync logging support.
* syncevolution.org packages: fixed D-Bus server autostart in .deb and .rpm packages
syncevo-dbus-server wasn't started automatically as part of a user
session because /etc/xdg/autostart/syncevo-dbus-server.desktop wasn't
included in the packages. This broke auto syncing after a session
restart (required manually starting SyncEvolution).
* syncevolution.org packages: support KDE
The traditional "syncevolution-evolution" package was
replaced with "syncevolution-bundle". A meta "syncevolution-evolution"
package depends on it, to support seamless updates for users who have
"syncevolution-evolution" installed.
Binary dependencies of the main .deb are ignored for backends
because loading them is optional. The new "syncevolution-kde"
package has the right dependencies for KDE/Akonadi, while
"syncevolution-evolution" mostly just lists standard libs
if the "EDS compatibility" mode is used, where libebook/libecal
are loaded dynamically.
Platform specific code (GNOME keyring, KDE wallet) was moved into
loadable, optional modules, to allow installation of the SyncEvolution
bundle without forcing the installation of unused system components.
* D-Bus: use GIO D-Bus instead of libdbus if available
When compiling from source, the more modern GIO D-Bus is used instead
of libdbus if available and recent enough (>= 2.30). syncevolution.org
binaries still use libdbus, to stay compatible with older Linux
distros.
* several minor bug fixes
syncevo-dbus-server now runs under valgrind in the nightly testing,
plus several more test scenarios were added. This helped to find
and fix various minor memory handling issues.
* developers: backend API changes
beginSync/endSync() (aka m_startDataRead/m_endDataWrite) may now be
called multiple times per SyncSource instance life cycle. SyncSources
derived from TrackingSyncSource should work without changes. Use the
Client::Source::*::testChangesMultiCycles test to check whether your
backend supports this correctly.
Reading and deleting must throw a 404 status exception when an item
is not found. The Client::Source::*::*404 tests cover this.
The special semantic of the former RegisterSyncSource::InactiveSource
(invalid pointer of value 1) caused bugs, like using it in
--print-databases (=> segfault) or not being able to store the result
of a createSource() directly in a smart pointer (=> potential leak in
SyncSource::createSource()).
Obviously a bad idea to start with. Replaced with a
RegisterSyncSource::InactiveSource() method which creates a real,
inactive SyncSource instance which can and must be deleted by the
caller.
This is a SyncSource API change for backend developers. Instead of
RegisterSyncSource::InactiveSource, return
RegisterSyncSource::InactiveSource(). Comparisons against
RegisterSyncSource::InactiveSource needs to be replaced with a call
to the new SyncSource::isInactive().
Long-running backend calls are encouraged to check for events on the
main glib context (either in a loop or with
g_main_context_iteration(NULL)) and abort when
SuspendFlags::getSuspendFlags().getState() returns
SuspendFlags::ABORT.
Implementing the improved local sync output required extending the
D-Bus API. The Server.LogOutput signal now has an additional
"process name" parameter. Normally it is empty. For messages
originating from the target side, it carries that extra target
context string.
This D-Bus API change is backward compatible. Older clients can still
subscribe to and decode the LogOutput messages, they'll simply ignore
the extra parameter. Newer clients expecting that extra parameter
won't work with an older D-Bus daemon: they'll fail to decode the
D-Bus message.
* packagers:
libgdbussyncevo is now installed as a normal library in /usr/lib,
even though SyncEvolution is the only user.
pcrecpp is now a new hard dependency.
Changes 1.2.99.4 -> 1.3
=======================
* D-Bus server + GIO D-Bus: shutdown fix
When compiled against GIO D-Bus (not the case in syncevolution.org
binaries), the syncevo-dbus-server occasionally shut down before
sending out all pending D-Bus messages. Showed up only in nightly
testing.
* D-Bus server + GIO D-Bus: fix auto-activation (Debian bug #599247)
When syncevo-dbus-server was started on demand by the D-Bus daemon,
then it registered itself with the daemon before it was ready to
serve requests. Only happened in combination with GIO D-Bus and
thus was not a problem before 1.2.99.x.
One user-visible effect was that the GTK UI did not select the default
service when it was started for the first time, because it could not
retrieve that information from syncevo-dbus-server.
* local sync: fix timeout with local sync with libdbus
When using libdbus instead of GIO D-Bus (as done by syncevolution.org
binaries and SyncEvolution on Maemo), local sync may have aborted
after 25 seconds when syncing many items with a D-Bus timeout error:
[ERROR] sending message to child failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible ca
Reported by Toke Høiland-Jørgensen for Harmattan. Somehow not encountered
elsewhere.
* KDE: check for D-Bus to avoid crash in KApplication (BMC #25596)
Some unnamed version of KDE crashes in KApplication when invoked
without a D-Bus session. The reporter ran into this when compiling
from source, because the SyncEvolution binary is invoked as part of
the build process, which ran outside of a D-Bus session.
Avoid the crash by checking for a D-Bus session bus before instantiating
KApplication. Instantiating KApplication was added for KWallet support.
Without D-Bus, KWallet does not work either, therefore throw an explicit
error when the lack of D-Bus is detected.
* Funambol: work around PHOTO TYPE=image/jpeg
A combination of Funambol Android and Funambol server recently led to
the Funambol server sending PHOTO data with TYPE=image/jpeg. This is
invalid and caused EDS to reject the photo (Vladimir Elisseev,
"[SyncEvolution] issues with syncing photos").
Work around the problem by only keeping the part of the type after the
last slash, if there is any. For image/jpeg and similar types that
leads to the desired value and does not affect valid values, because
those do not contain a slash
(http://www.iana.org/assignments/media-types/image/index.html).
* syncevo-http-server: fixed printing of server debug output
Python failed to call logSyncEvoOutput() after adding the additional
'process' parameter to LogOutput because it extracts all four
parameters and then cannot pass them to logSyncEvoOutput().
Now logSyncEvoOutput() uses the new process information to instantiate
a logger with the right prefix, using 'sync' as fallback for messages
without that information (as before).
* Some minor code and test cleanup.
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2012/syncevolution-13-released
Source code bundles for users are available in
http://downloads.syncevolution.org/syncevolution/sources
and the original source is in the git repositories
http://cgit.freedesktop.org/SyncEvolution/
i386, lpia and amd64 binaries for Debian-based distributions are
available via the "stable" syncevolution.org repository. Add the
following entry to your /apt/source.list:
deb http://downloads.syncevolution.org/apt stable main
Then install "syncevolution-evolution", "syncevolution-kde" and/or
"syncevolution-activesync".
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy), except for "syncevolution-activesync" which
depends on libraries in Debian Squeeze, for example EDS 3.4.
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/. In contrast
to 0.8.x archives, the 1.x .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
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
6 years, 1 month
[SyncEvolution] SyncEvolution + IVI + unified address book
by Patrick Ohly
Hello!
I've started working on some in-vehicle infotainment (IVI) use cases.
This will combine work done in SyncEvolution, in particular the PBAP
caching, EDS, and libfolks into a building block for an IVI head unit,
the computer which is built into the car.
The building block is meant to be used via an IPC mechanism like D-Bus,
without having to link against glue libraries. Conceptually, the block
is sitting above SyncEvolution and could be implemented separately. The
D-Bus API is defined such that an independent implementation would be
possible. I reserved a D-Bus name space by creating a "PIM" project on
OTC's 01.org site (not live yet).
In practice, the implementation is done as part of SyncEvolution's
syncevo-dbus-server. That simplifies the interaction with SyncEvolution
and avoids having to start and run too many separate processes. Unless
someone has a better idea and place, I'll use the SyncEvolution mailing
list to discuss also this new aspect of SyncEvolution.
I have some partial implementation of the API ready and will push it
shortly to the new SyncEvolution git repo on freedesktop.org (will
announce that repo separately).
More important than the implementation is the API itself. It would be
good if someone could review it with an eye towards bad D-Bus practices,
usability, documentation, etc. Therefore let me finish the email with a
complete dump of the current API description:
-----------------------------------------------------------------
Preamble
========
This text describes a D-Bus API. It might get copied into XML API definitions
in future revisions.
The API implements in-vehicle infotainment (IVI) use cases around
contacts:
- cache address books from peers (primarily phones connected via Bluetooth)
in local address books
- provide a unified address book that combines a configurable (and changing)
subset of the local address books
- fast phone number lookup
- browsing and searching in the unified address book
Tasks that are expected to be done by the user of this API:
- identify peers and their capabilities
- decide how and when peer data should be cached
- define which data goes into the unified address book
In other words, the API provides the mechanisms and the user the
policy.
Datatypes
=========
Peers
-----
A peer is an entity which has exactly one address book that is meant
to be cached locally. Typically a peer is a phone connected via
Bluetooth and accessed via PBAP, but it could also be a web service
that supports CardDAV or a phone with SyncML support.
Peers are identified by a unique string ID. That ID needs to be
assigned by the user of this API. The string must not be empty and may
only contain characters a-z, 0-9, hyphen and colon. No other
assumptions about its content are made. For example, the phone's
Bluetooth MAC address could be used.
For an entity that has more than one address book, multiple peers must
be configured.
For each peer, enough information must be provided to access its
address book. That information is passed via D-Bus as a
string-to-string dict, with the following keys:
- "protocol" - defines how to access the address book. Currently
only "PBAP" is implemented. "SyncML", "CardDAV" are documented
to illustrate how the API would work for them.
- "transport" - defines how to establish
the connection. Currently only "Bluetooth" is allowed
(for protocol=PBAP or SyncML) and taken as default when
"transport" is not set.
- "address" - the Bluetooth MAC address in the aa:bb:cc:dd:ee:ff
format (for transport=Bluetooth)
- "database" - empty or unset for the internal address book
(protocol=PBAP), the URI (protocol=SyncML)
Address books
-------------
Address books which mirror data from a specific peer use the string
"peer-<uid>" as ID, where <uid> is the unique ID of that peer.
In addition, there is a system address book which is independent of
any particular phone. Its ID is the empty string.
This naming scheme can be extended later on, to support other kinds
of address books.
Contact
-------
A single contact is transferred via D-Bus as a string->variant dict
where the keys are predefined property names and the values represent
simple values (a string for "full-name") or more complex structures
(list of phone numbers for "phone-numbers", with each list entry
itself being a combination of type flags and the actual value).
[comment: this mirrors the properties of a libfolks Individual:
http://telepathy.freedesktop.org/doc/folks/c/FolksIndividual.html]
Some properties of a FolksIndividual only make sense locally and are
not transmitted, for example the personas it is derived from.
Some other properties provide information not found that way in
FolksIndividual:
- "source" = list of string pairs, where each pair is a combination
of address book ID and local contact ID inside that address book
(not necessarily the same as the vCard UID of a contact!)
Property values which are large (like photos) are not sent via
D-Bus. Instead a link to a local file is sent.
TODO: document all properties and their types.
Search results
--------------
The goal is to support a UI which:
- displays an ordered list of the search result,
- can show the initial results with minimal delay,
- can load actual content for the display as needed (only
load the parts which are visible or will be visible soon).
The content of the unified address book can change at any time. The
API design takes that into account by using a model/view/controller
model.
The model is the complete list of contacts, sorted according to the
currently configured sort order. Sorting is part of the model to
simplify generating views.
The view is the subset of the data that a user of the API has
requested. In the most extreme case, all contacts are part of the
view. Therefore contact data has to be requested explicitly. To
support requesting data in batches, contacts are numbered 0 to n-1 in
each view, where n is the number of contacts in the view. Sort order
is the same as in the underlying model. Change notifications with
these index numbers are sent as contacts are added, modified or
removed.
The controller is the part of the API which allows changing contacts
in the system address book, changing the sort order, enabling or disabling
address books, etc.
Note that removing or adding a contact changes the numbers assigned to
other contacts. Example:
- A view containing 10 contacts is created.
- A notification about "contacts #0 to #9 added" is sent
(given as pair of first index and count, not list of numbers).
- Data for contacts #5 to #19 gets requested, five contacts #5 to #9
are returned. It's okay to ask for more contacts than exist,
because the caller cannot be sure anyway how many contacts
still exist at the time when the request gets processed.
- Contact #4 gets removed. The user needs to remember that
the data that it has now corresponds to contacts #4 to #8.
- Contact #5 gets added, before the contact which had that
number before. The user now has contacts #4 and #6 to #9.
It should request contact #5 if (or once) it is needed to
provide a complete list to the user.
[comment: using a view could be simplified by including contact data
in the change notifications. This is not planned at the moment because
it would not work well for large views. When adding it, there should
be an API to restrict which properties of a contact get sent.]
Error handling
==============
D-Bus error messages are not localized. They are meant for debugging,
not for displaying to the user. In cases where the caller may be able
to do something about an error, specific error codes could be defined
and returned as part of the API. However, typically errors are generic
and the caller simply has to assume that the PIM storage is currently
unusable.
Unless noted otherwise, calls return when the requested operation is
complete.
API
===
PIM Manager
-----------
The PIM manager is used to hold the unified address book in memory,
create views on it, change configuration and control data transfers
from phones.
Service: org._01.pim.contacts
Interface: org._01.pim.contacts.Manager
Object path: /org/01/pim/contacts
Methods:
void Start()
The PIM manager does not start loading contact data right
away. That allows setting the options like sort order first
and/or delaying the loading until it is needed. After
Start(), changing options that affect the unified address
book will take effect immediately.
Calling Start() is optional, any method asking for data will
automatically do that.
void Stop()
Explicitly tells the PIM manager to discard the unified address
book and free up the memory if possible (= not currently in use).
Primarily useful for testing.
void SetSortOrder(string mode)
"mode" must be one of "first/last", "last/first", "full name".
"first/last" sorts based on the first name stored in the "name"
property, with the last name used to break ties between equal first
names. "last/first" reverts that comparison. "full name" sorts based on
the full name chosen for the contact if there is such a string, otherwise
it uses "<last name>" and "<first name>" as sort strings.
The sort order is stored persistently. The default is "last/first".
string GetSortOrder()
Returns the current sort order.
list of strings GetActiveAddressBooks()
Returns the IDs of the address books which currently
contribute to the unified address book.
void SetActiveAddressBooks(list of strings)
Sets the address books which contribute to the unified
address book.
void SetPeer(string uid, dict properties)
Adds or modifies a peer. Modifying a peer does *not* affect
any contact data which might be cached for it.
void RemovePeer(string uid)
Removes a peer and all its cached data. If that data was
part of the active address books, it will be removed
automatically.
void SyncPeer(string uid)
Retrieve contacts from the peer and ensure that the local
cache is identical to the address book of the peer. The call
returns once the operation is complete. Only if there was no
error can the caller assume that the cache is up-to-date.
Otherwise it is in an undefined state.
void StopSync(string uid)
Stop any running sync for the given peer. The SyncPeer() method
which started such a sync will return with an "aborted" error
once the sync was stopped.
dict of UID to string key/value dict GetAllPeers()
Returns information about all currently configured peers.
object Search(dict filter, object agent)
Creates a new view which contains all contacts matching the
filter. The call returns the object path of a view object
after validating parameters and starting the result
gathering, and before completing the search. The view object
can be used to control the view via the
org._01.pim.contacts.ViewControl interface.
An empty filter matches all contacts. TODO: define other
searches.
Notifications for the view are sent back to the caller by
invoking methods from the org._01.pim.contacts.ViewAgent
interface on the object whose path is given in the "view"
parameter. If any of these method calls fail, the view will
automatically be destroyed.
In other words, the caller first needs to get ready to process
results by registering an object on the bus before calling
Search().
[comment: this allows sending results to just one recipient,
something that cannot be done easily with the use of signals as in,
for example, obexd. In obexd, the initiator of a transfer
has to subscribe to org.bluez.obex.Transfer on the object path
returned to it when starting the transfer, then check the current
status before waiting for signals, because the "Completed" signal
might have been sent before it could register for it.]
string AddContact(string addressbook, dict contact)
Adds a new contact to the given address book. Typically
only the system address book is writable. Contact properties
which are unknown or cannot be stored are silently ignored.
Returns the local ID of the new contact in the address book.
Photo data that is sent inline in the dict will be split out
into a file that gets associated with the contact. A photo
file that gets linked will continue to be owned by the
caller; the contact storage may or may not make a copy of it,
depending on which storage is used.
void ModifyContact(string addressbook, string localid, dict contact)
Updates an existing contact.
void RemoveContact(string addressbook, string localid)
Remove the contact and all of its associated data (like the
photo, if the photo file is owned by the contact storage).
Service: org._01.pim.contacts
Interface: org._01.pim.contacts.ViewControl
Object path: [variable prefix]/{view0,view1,....}
Methods:
list of contact dicts ReadContacts(int start, int count)
Requests at most "count" contacts in the view, starting
with the one at "start" (numbered starting with 1). May
return less (or no) contacts if the request range is
beyond the end of the view at the time when the call is
processed.
Note that the caller must process the call response
after all events via the ViewAgent interface if it wants
to keep in sync with the view. Doing this call asynchronously
and dealing with the response as part of the main event
loop will do the right thing automatically, because D-Bus
guarantees ordering of messages.
Making this explicit by returning data via another
org._01.pim.contacts.ViewAgent method was considered and
rejected a) for the sake of keeping this API simple and
b) to allow simple synchronous calls where it makes sense
(testing, for example).
void Close()
Closes the view and all resources associated with it.
Pending ReadContacts() calls will return without any
data and no error.
void RefineSearch(dict filter)
Replaces the current filter of the view with a new one.
The new filter must be stricter than the old one. Contacts
which were already filtered out will not be added back
to the view when setting a less restrictive filter (simplifies
the implementation).
Service: [user of the PIM Manager]
Interface: org._01.pim.contacts.ViewAgent
Object path: [as chosen by user of PIM Manager]
Methods:
void ContactsModified(object view, int start, int count)
Contacts #start till #start + count (inclusive) have
changed. Data that the recipient of the call might have
cached became invalid and should be reloaded. In cases
where changing a contact changes its position in the
sorted list, "contact removed" and "contact added"
notifications will be triggered instead of a "contact
changed".
void ContactsAdded(object view, int start, int count)
New contacts were added to the view.
The contact which previously had index #start now
has index #start + count, etc.
void ContactsRemoved(object view, int start, int count)
Some contacts were removed from the view.
The contact which previous had index #start + count
(if there was one) now has index #start, etc.
-----------------------------------------------------------------
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7 years, 1 month
[SyncEvolution] Reason for libsynthesis 3.4.0.16.8 dependency
by tino.keitel+syncevolution＠tikei.de
Hi Patrick,
I'm looking for the reason why syncevolution 1.3 requires libsynthesis
3.4.0.16.8. I'm not shure what to look for. Could you point me to
specific commits in syncevolution? The dependency change in
configure.ac came in with a commit that also added a lot of stuff to
the NEWS file.
Regards,
Tino
7 years, 2 months
[SyncEvolution] syncevolution --configure hangs
by tino.keitel+syncevolution＠tikei.de
Hi,
I tried the following:
syncevolution --configure autoSyncInterval=30 eazy
This command does not return. According to strace, it seems to wait
forever in poll().
Adding --daemon=no to the options does not hang.
Subsequent sync runs will also hang.
This happens with 1.3.1 with commit
d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
Regards,
Tino
7 years, 2 months
Re: [SyncEvolution] Syncing between N9 and KDE's Kontact (Akonadi)?
by Patrick Ohly
Hello!
Nikos' emails don't get through the mailing list server because it
expects delivering machines to have valid DNS entries.
On Mon, 2012-11-12 at 19:00 +0200, Nikos Alexandris wrote:
> Greetings to the list(-ers)!
>
> I tried a few weeks ago to get hands on syncevolution(-kde, version 1.3.1) and
> N9 (MeeGo). I have gone through the following steps:
>
> ---%<---
> syncevolution --print-databases
> # returns all of my "sources" as seen in Kontact: kde-contacts as:
> # akonadi:?collection=SomeNumber
> # the same for kde-calendar, kde-tasks and kde-memos
>
> syncevolution --configure keyring=KDE <...>
> # using the correct database=akonadi:?collection=SomeNumber for each "source"
>
> syncevolution --print-items @default addressbook
> # returns 397 different numbers
> -->%---
>
> So far so good. Afterwards, trying to sync (either via CLI or the Sync GUI) a
> dialog asking for a password appears. Where and how should this password be
> configured?
What does the dialog ask for?
It could be the dialog about unlocking the KWallet, but it is hard to be
sure without more information.
> I have posted (about) this on the blog [1][2]. Does the blog attract
> attention? Any success story?
> [1] <https://syncevolution.org/wiki/kde-akonadi#comment-821>
> [2] <https://syncevolution.org/wiki/nokia-n9-compatibility-template>
It is better to ask for help here. I used to monitor comments on
syncevolution.org, but not regularly and lately new comments no longer
show up in the feed of the site, which makes it very likely that I miss
them.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7 years, 2 months
[SyncEvolution] consept is too complicated
by Ildar Mulyukov
Hello, Patrick, community.
1st of all I wanted to convince you that I appreciate SyncEvolution.
This is a great piece of software, and what's most important: it works.
But now I wanted to raise one question: do you intend to refactor the
design of it?
I mean I just read out the
https://syncevolution.org/documentation/syncevolution-usage#terminology
and it is statistically:
Lines 29
Words 837
Symbols 5155
This means tens of concept terms! I mean: it's not easy to understand
and surely takes noticeable effort to get used to. This is especially
wonderful knowing that opensync was already there, which had _much_
simpler design (while I understand that it may not cover all the needs
that syncevo deal with).
I don't mean to criticize but just ask: do you plan to do something
with it, say, for the next major release?
Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
home: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
7 years, 2 months
[SyncEvolution] updating libsynthesis for SyncEvolution
by Patrick Ohly
Hello!
The libsynthesis as used by SyncEvolution (the "master" branch in
freedesktop.org) was updated to almost the same revision as Lukas'
upstream code in the "luz" branch of the gitorious repo.
What is missing is the latest commit:
-------------------------------------------------
commit 8226bd4988f8a00fe391130af43850a1c90b2aa5
Author: Lukas Zeller <luz(a)plan44.ch>
Date: Wed Oct 10 21:53:22 2012 +0200
SyncModeExtensions: added config flag <syncmodeextensions> that must
be set in config to enable non-standard sync modes to be added into
config. This is because some servers fail to work when non-standard
modes are present, so by default they are off now.
Projects that rely on the sync mode extensions (SyncEvolution) must
enable them explicitly in config now
-------------------------------------------------
Before using that commit, a config option must be added to SyncEvolution
to control the usage of the sync mode extension mechanism.
I'll refrain from commenting about the quality of the SyncML servers
which fail to handle extensions of the sync mode list - an array that
was meant to negotiate extensions...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7 years, 2 months
[SyncEvolution] merging Maemo + Harmattan changes into master
by Patrick Ohly
Hello Ove!
I've imported your git repos and merged the Maemo+Harmattan changes back
into current master.
While reviewing the resulting diff against master I found some oddities
and reverted some of the changes before committing the merged state.
Details are in the commit message:
commit 340579cbdbd8f630846d85319b274a3e41a6313a
Merge: 6648a36 0d86dc1
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Thu Nov 1 14:39:31 2012 +0100
Merge branch 'HARMATTAN-1-3-1'
Fetched the code and its history from the 1.3.1 archives at:
http://people.debian.org/~ovek/maemo/
http://people.debian.org/~ovek/harmattan/
Merged almost everything, except for Maemo/Harmattan specific build files:
autogen-maemo.sh builddeb buildsrc debian
The following changes were also removed, because they are either local
workarounds or merge artifacts which probably also don't belong into
the Maemo/Harmattan branch:
diff --git a/configure.ac b/configure.ac
index cb66617..2c4403c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,7 @@ if test "$enable_release_mode" = "yes"; then
AC_DEFINE(SYNCEVOLUTION_STABLE_RELEASE, 1, [binary is meant for end-users])
fi
-AM_INIT_AUTOMAKE([1.11.1 tar-ustar silent-rules subdir-objects -Wno-portability])
+AM_INIT_AUTOMAKE([subdir-objects -Wno-portability])
AM_PROG_CC_C_O
diff --git a/src/backends/webdav/CalDAVSource.cpp b/src/backends/webdav/CalDAVSource.cpp
index decd170..7d338ac 100644
--- a/src/backends/webdav/CalDAVSource.cpp
+++ b/src/backends/webdav/CalDAVSource.cpp
@@ -1282,6 +1282,7 @@ void CalDAVSource::Event::fixIncomingCalendar(icalcomponent *calendar)
// time.
bool ridInUTC = false;
const icaltimezone *zone = NULL;
+ icalcomponent *parent = NULL;
for (icalcomponent *comp = icalcomponent_get_first_component(calendar, ICAL_VEVENT_COMPONENT);
comp;
@@ -1295,6 +1296,7 @@ void CalDAVSource::Event::fixIncomingCalendar(icalcomponent *calendar)
// is parent event? -> remember time zone unless it is UTC
static const struct icaltimetype null = { 0 };
if (!memcmp(&rid, &null, sizeof(null))) {
+ parent = comp;
struct icaltimetype dtstart = icalcomponent_get_dtstart(comp);
if (!icaltime_is_utc(dtstart)) {
zone = icaltime_get_timezone(dtstart);
diff --git a/src/backends/webdav/CalDAVSource.h b/src/backends/webdav/CalDAVSource.h
index 517ac2f..fa7c2ca 100644
--- a/src/backends/webdav/CalDAVSource.h
+++ b/src/backends/webdav/CalDAVSource.h
@@ -45,6 +45,10 @@ class CalDAVSource : public WebDAVSource,
virtual void removeMergedItem(const std::string &luid);
virtual void flushItem(const string &uid);
virtual std::string getSubDescription(const string &uid, const string &subid);
+ virtual void updateSynthesisInfo(SynthesisInfo &info,
+ XMLConfigFragments &fragments) {
+ info.m_backendRule = "HAVE-SYNCEVOLUTION-EXDATE-DETACHED";
+ }
// implementation of SyncSourceLogging callback
virtual std::string getDescription(const string &luid);
Making SySync_ConsolePrintf a real instance inside SyncEvolution leads
to link errors in other configurations. It really has to be extern. Added
a comment to the master branch to make that more obvious:
-extern "C" { // without curly braces, g++ 4.2 thinks the variable is extern
- int (*SySync_ConsolePrintf)(FILE *stream, const char *format, ...);
-}
+// This is just the declaration. The actual function pointer instance
+// is inside libsynthesis, which, for historic purposes, doesn't define
+// it in its header files (yet).
+extern "C" int (*SySync_ConsolePrintf)(FILE *stream, const char *format, ...);
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7 years, 2 months
