autotools, NEWS: SyncEvolution 1.4.99.3syncevolution-1-4-99-3

2 files changed, 187 insertions, 1 deletions

diff --git a/NEWS b/NEWS
index 74cc30fd..90880736 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,189 @@
+SyncEvolution 1.4.99.2 -> 1.4.99.3, 23.07.2014
+==============================================
+
+This release enhances CalDAV/CardDAV and PBAP syncing and fixes some
+problems. The enhanced conflict handling introduced 1.4.99.2 was
+unintentionally limited to syncs with EDS on the server side; it is
+now also available for example in WebDAV<->SyncML bridge setups.
+
+Details:
+
+* CardDAV: implement read-ahead
+
+  Instead of downloading contacts one-by-one with GET, SyncEvolution now
+  looks at contacts that are most likely going to be needed soon and
+  gets all of them at once with addressbook-multiget REPORT.
+
+  The number of contacts per REPORT is 50 by default, configurable by
+  setting the SYNCEVOLUTION_CARDDAV_BATCH_SIZE env variable.
+
+  This has two advantages:
+  - It avoids round-trips to the server and thus speeds up a large
+    download (100 small contacts with individual GETs took 28s on
+    a fast connection, 3s with two REPORTs).
+  - It reduces the overall number of requests. Google CardDAV is known
+    to start issuing intermittent 401 authentication errors when the
+    number of contacts retrieved via GET is too large. Perhaps this
+    can be avoided with addressbook-multiget.
+
+* Google Calendar: remove child hack, improve alarm hack (FDO #63881)
+
+  Google recently enhanced support for RECURRENCE-ID, so SyncEvolution
+  no longer needs to replace the property when uploading a single
+  detached event with RECURRENCE-ID. However, several things are still
+  broken in the server, with no workaround in SyncEvolution:
+  - Removing individual events gets ignored by the server;
+    a full "wipe out server data" might work (untested).
+  - When updating the parent event, all child events also get
+    updated even though they were included unchanged in the data
+    sent by SyncEvolution.
+  - The RECURRENCE-ID of a child event of an all-day recurring event
+    does not get stored properly.
+  - The update hack seems to fail for complex meetings: uploading them
+    once and then deleting them seems to make uploading them again
+    impossible.
+
+  All of these issues were reported to Google and are worked on there,
+  so perhaps the situation will improve. In the meantime, syncing with
+  Google CalDAV should better be limited to:
+  - Downloading a Google calendar in one-way mode.
+  - Two-way syncing of simple calendars without complex meeting
+    serieses.
+
+  While updating the Google workarounds, the alarm hack (sending a
+  new event without alarms twice to avoid the automatic server side
+  alarm) was simplified. Now the new event gets sent only once with a
+  pseudo-alarm.
+
+* ephemeral sync: don't write binfile client files (FDO #55921)
+
+  When doing PBAP caching, we don't want any meta data written because
+  the next sync would not use it anyway. With the latest libsynthesis
+  we can configure "/dev/null" as datadir for the client's binfiles and
+  libsynthesis will avoid writing them.
+
+  The PIM manager uses this for PBAP syncing automatically. For testing
+  it can be enabled by setting the SYNCEVOLUTION_EPHEMERAL env variable.
+
+* PBAP: avoid empty field filter
+
+  Empty field filter is supposed to mean "return all supported
+  fields". This used to work and stopped working with Android phones
+  after an update to 4.3 (seen on Galaxy S3); now the phone only
+  returns the mandatory TEL, FN, N fields.
+
+  The workaround is to replace the empty filter list with the list of
+  known and supported properties. This means we only pull data we really
+  need, but it also means we won't get to see any additional properties
+  that the phone might support.
+
+* PBAP: transfer in chunks (FDO #77272)
+
+  If enabled via env variables, PullAll transfers will be limited to
+  a certain numbers contacts at different offsets until all data got
+  pulled. See PBAP README for details.
+
+  When transfering in chunks, the enumeration of contacts for the engine
+  no longer matches the PBAP enumeration. Debug output uses "offset #x"
+  for PBAP and "ID y" for the engine.
+
+* PBAP: remove transfer via pipe
+
+  Using a pipe was never fully supported by obexd (blocks
+  obexd). Transfering in suitably sized chunks (FDO #77272) will be a
+  more obexd friendly solution with a similar effect (not having to
+  buffer the entire address book in memory).
+
+* engine: enable batching by default (FDO #52669)
+
+  This reverts commit c435e937cd406e904c437eec51a32a6ec6163102.
+
+  Commit 7b636720a in libsynthesis fixes an unitialized memory read in
+  the asynchronous item update code path.
+
+  Testing confirms that we can now used batched writes reliably with EDS
+  (the only backend currently supporting asynchronous writes +
+  batching), so this change enables it again also for local and
+  SyncEvolution<->SyncEvolution sync (with asynchronous execution of
+  contact add/update overlapped with SyncML message exchanges) and other
+  SyncML syncs (with changes combined into batches and executed at the
+  end of each message).
+
+* datatypes: fix contact caching
+
+  Adding grouping to the contact datatype in 1.4.99.2 broke PBAP caching: when
+  sending an empty URL, for example, during the sync, the parsed contact
+  had different field arrays than the locally stored contact, because the
+  latter was saved without the empty URL.
+
+  This caused the field-based comparison to detect a difference even when
+  the final, reencoded contact wasn't different at all.
+
+  To solve this, syncing now uses the same "don't send empty properties"
+  configuration as local storages. Testing shows that this resolves
+  the difference for EDS.
+
+  A more resilient solution would be to add a check based on the encoded
+  data, but that's more costly performance wise.
+
+* datatypes: fix vCard handling
+
+  The new "preserve repeating properties during conflict resolution"
+  feature from 1.4.99.2 was only active when using EDS as storage. The relevant
+  merge script must be applied to all datatypes, not just the EDS
+  flavor.
+
+  The feature was also unintentionally active when running in
+  caching mode. This caused two problems:
+  - The cached item was updated even though only the
+    ordering of repeating properties had been modified during
+    merging.
+  - The merged item was sent back to the client side, which
+    was undesirable (caching is supposed to be one-way) or even
+    impossible (PBAP is read-only, causing sync failures eith error 20030).
+
+  We must check for caching mode and disable merging when it is active.
+  We also must not tell the engine that we updated the photo property
+  in the winning item, because then that item would get sent to the
+  read-only side of the sync.
+
+  Perhaps a better solution would be to actually tell the engine
+  that the remote side is read-only when we activate caching mode.
+
+* datatypes: avoid PHOTO corruption during merge (FDO #77065)
+
+  When handling an update/update conflict (both sides of the sync have an
+  updated contact) and photo data was moved into a local file by EDS, the engine
+  merged the file path and the photo data together and thus corrupted the photo.
+
+  The engine does not know about the special role of the photo property.
+  This needs to be handled by the merge script, and that script did not
+  cover this particular situation. Now the loosing side is cleared,
+  causing the engine to then copy the winning side over into the loosing
+  one.
+
+  Found by Renato Filho/Canonical when testing SyncEvolution for Ubuntu 14.04.
+
+* PBAP syncing: updated photo not always stored
+
+  Because photo data was treated like a C string, changes after any
+  embedded null byte were ignored during a comparison.
+
+* PIM: fix phone number normalization
+
+  The parsed number always has a country code, whereas SyncEvolution expected it
+  to be zero for strings without an explicit country code. This caused a caller
+  ID lookup of numbers like "089788899" in DE to find only telephone numbers in
+  the current default country, instead of being more permissive and also finding
+  "+189788899". The corresponding unit test was broken and checked for the wrong
+  result. Found while investigating an unrelated test failure when updating
+  libphonenumber.
+
+* Various compiler problems and warnings fixed; compiles with
+  --with-warnings=fatal on current Debian Testing and Ubuntu Trusty
+  (FDO #79316).
+
+
 SyncEvolution 1.4.99.1 -> 1.4.99.2, 23.05.2014
 ==============================================
 
diff --git a/configure.ac b/configure.ac
index faa52d7c..165af7d4 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.4.99.2])])
+AC_INIT([syncevolution], [m4_esyscmd([build/gen-git-version.sh 1.4.99.3])])
 # STABLE_VERSION=1.0.1+
 AC_SUBST(STABLE_VERSION)