NEWS, configure: updated for 1.2.99.2
This commit is contained in:
Patrick Ohly
parent
8b86963466
commit
a2ebc922ca
127
NEWS
127
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
|
||||
===========================================
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue