NEWS, configure: updated for 1.2.99.2

2 files changed, 128 insertions, 1 deletions

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)