>Please let me know if that sounds ok to you.
Pretty good for me.
By the way, I have made a test for google server, It still sends 200 for a
<Add> cmd. The workaround looks meaningful for this Bizarre behavior.
>I can help implementing the sop_add and the config option in the
>engine, as I'll have to check the implications and apply fixes in the
>non-OS part of our codebase anyway.
Thanks for your help!
If I understand correctly, the existing code has a bug in implGetItem:
The assumption: "records detected new/changed now will inevitably be
new or changed in all other profiles" seems to me not reasonable. Please
correct me if I lost something.
Suppose we have record K and server A,B
1. sync with A, suspended.
2. K gets updated.
3. sync with B, K.syncmod=3, sending K.
4. sync with A, resume, K.syncmod=5
5. sync with B, K will be resended.
Looks like we cannot avoid to add a flag to indicate such special case.
----
Code attached below:
if (isResuming()) {
if (!(chglogP->flags & chgl_markedforresume)) {
// not marked for resume, but check if it has changed after the last suspend
if (chglogP->modcount<=fPreviousSuspendModCount) {
continue; // not for resume - check next
}
else {
// New behaviour here from 3.1.5.2 onwards:
// Note that this also affects other profiles as there is only one single
changelog -
// however, this is not a problem because the records detected new or
changed now
// will inevitably be new or changed in all other profiles as well. So we
can
// safely touch these record's modcount w/o any noticeable side effects in
other profiles.
}
}
---
Regards,
Congwu
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
