Hello Patrick, I owe you an answer regarding commits 0e139ee311 and 4275e77001:
On Sep 13, 2010, at 16:42 , Patrick Ohly wrote: >> 1) 0e139ee311 (engine 3.4.0.10: separate changelogs, pendingmaps and >> pendingitem for each profile to allow for different syncsets in >> profiles (as needed by SyncML PRO iOS)): >> >> This change is transparent as long as the app using libsynthesis does >> not mess with the *.bfi files directly, especially make assumptions >> about their names. It is possible to stay with the old unified >> changelog for applications not using more than one profile (by >> explicitly turning off the new separate changelogs in the config), but >> I would recommend to use the new way because the old way is deprecated >> and might be removed entirely later. > > SyncEvolution has already worked the new way by using separate bin > directories for each peer. > > The commit message says that transition to the new format is done > automatically. Doesn't this prevent downgrading? Not entirely, but changelogs will be lost when going back which will force a slow sync. But altough going back is possible here, the binfile store generally does not provide going back (that is, without loosing all settings), only forward. As soon as something changes in the data format, the DB version field in the binfile is incremented, and it will no longer be compatible with the previous version. > While is not always possible, we try to support that in SyncEvolution as > often as possible. > > Is there a way to avoid the automatic conversion and continue writing in > the old format? Yes, you can set <separatechangelogs> (within <datastore>) to false to keep using the old method. However, I would recommend that only as a temporary solution, for example to retain backward compatibility until the next major release (where breaking it is probably more acceptable than between minor revisions). In the long term perspective, I'd like to remove the old method, because it simply does not work correctly with multiple profiles, and multiple profiles is something the engine does have and should work. >> 2) 4275e77001 (engine: refined folding for pre-MIME-DIR and MIME-DIR - >> new "foldbetween" <property> attribute.): >> >> This changes the way folding occurs in pre-MIME-DIR formats (vCard >> 2.1, vCalendar 1.0), as it no longer inserts extra spaces to break >> long multi-value properties with no spaces in the values, but instead >> uses QP (as it already did for single-value properties with no spaces >> in the value). However, as the new (correct) behaviour probably causes >> more troubles for poor implementation with multi-values like EXDATES, >> there's now a new property-level config option to allow inserting a >> space between value and value separator when needed to wrap long >> lines. With this, EXDATES is rendered similar as before (before the >> spaces were inserted AFTER the separator, which caused a extra LEADING >> space, while now it will be an extra TRAILING space). >> >> So the recommendation is to add foldbetween="yes" in the config for >> EXDATES (and possibly other semantically similar properties). > > What are such other properties? Anything which has a separator in the > value? I'd say those where the probability for correct parsing by cheap implementations is better with an extra space, but unchopped individual values. In my setups, the only candidate is EXDATES. Other multi-values like ADR suffer more from the extra space, and for these parsers more likely can handle unfolding correctly. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
