From a2ebc922ca2662601c49c6ad3f297d3fa33427ac Mon Sep 17 00:00:00 2001 From: Patrick Ohly Date: Sat, 30 Jun 2012 07:32:22 +0200 Subject: [PATCH] NEWS, configure: updated for 1.2.99.2 --- NEWS | 127 +++++++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 2 +- 2 files changed, 128 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index f9de42af..cf5e97ed 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,130 @@ +SyncEvolution 1.2.99.1 -> 1.2.99.2, 30.06.2012 +============================================== + +Next step towards SyncEvolution 1.3. It adds a workaround for +Funambol's OneMedia and fixes an old bug which became more severe in +1.2.99.1. Also has some usability improvements for +CalDAV/CardDAV. Hopefully it will not take long to stabilize the code, +so test it now while it is still hot :-) + + +Details: + +* 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. + +* 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. + +* 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. + +* 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. + +* 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 1 + + 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 + ermanent (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. + +* command line: fixed password + property lookup during --print-databases + + --print-databases for an existing configuration did not look up + passwords stored in a keyring, causing the operation to fail for + backends like CalDAV/CardDAV where credentials are required. + + Overriding source properties in that case also only worked when using + the unqualified property name ("databasePassword=foo") but not when + using the source name as prefix ("calendar/databasePassword=foo"). + +* Developers: + + 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. + + SyncEvolution 1.2.2 -> 1.2.99.1, 22.06.2012 =========================================== diff --git a/configure.ac b/configure.ac index 68ad60f4..159545ea 100644 --- a/configure.ac +++ b/configure.ac @@ -8,7 +8,7 @@ dnl Invoke autogen.sh to produce a configure script. # # Starting with the 1.1 release cycle, the rpm-style # .99 pseudo-version number is used to mark a pre-release. -AC_INIT([syncevolution], [m4_esyscmd([build/gen-git-version.sh 1.2.99.1])]) +AC_INIT([syncevolution], [m4_esyscmd([build/gen-git-version.sh 1.2.99.2])]) # STABLE_VERSION=1.0.1+ AC_SUBST(STABLE_VERSION)