Hi Congwu,
Per the discussion, I implemented a correct change log detection
based on multi-profile and Lukas will work further [...]
sorry, my fault - I found that you send an implementation patch by
mail I obviously didn't see.
I just reviewed and complemented it (when changing the changelog entry
struct, the DB version for the changelog must be updated and a update
function needs to be implemented to allow smooth transition for
existing installations).
It's now on the luz branch of [email protected]:libsynthesis.git
For now, the second part is not yet done:
- make the decision if sop_add is sent as a <Replace> or a <Add>
depending
on a config option, so we can use both variants (of course, only
for clients).
- only in case we disguise sop_add as <Replace>, apply the statistics
workaround when checking for status.
This way we would have the choice between a 100% clean behaviour
(undisguised adds) and an optional compatibility workaround mode. If
SyncEvolution testing shows that there are servers having problems
with client-side <Add> you can run it in workaround mode.
So now, the engine runs in "100% clean behaviour" mode. I guess it
makes sense to test with your target servers if there is any problem
with this. If so, just let me know and I'll add the config option
quickly. Otherwise, I'll keep it on a todo list for future improvements.
Best Regards,
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
