Hello Congwu!
I have a question about abort handling and hope that you remember how
this was meant to work. Did we want to abort instead of sending a
message that was just generated by the Synthesis engine?
According to your code comment, this was the goal:
//check for abort, if so, modify step command for next step.
//We think abort is useful when the server is unresponsive or
//too slow to the user; therefore, we can delay abort at other
//points to this two points (before sending and before receiving
//the data).
if (checkForAbort() && (stepCmd == sysync::STEPCMD_RESENDDATA
|| stepCmd ==sysync::STEPCMD_SENDDATA
|| stepCmd == sysync::STEPCMD_NEEDDATA)) {
stepCmd = sysync::STEPCMD_ABORT;
}
I tried to abort before sending a message via some other means (script
sets a flag, flag gets checked in addition to checkForAbort()) and found
that this didn't work:
* SessionStep() returns STEPCMD_SENDDATA
* our case statement for that starts sending, then sets
STEPCMD_SENTDATA
* the code above is invoked, but doesn't abort
* SessionStep() is called with STEPCMD_SENTDATA, returns
STEPCMD_NEEDDATA
* our case statement for that waits, eventually might end up in
TransportAgent::FAILED (which checks for abort by itself) or
TransportAgent::GOT_REPLY (which doesn't check for abort and
instead goes to STEPCMD_GOTDATA)
In none of these cases does the checkForAbort() quoted above have any
effect, as far as I can tell. Do you know in which case it is needed?
Do we miss a check for abort directly after SessionStep and/or should
the code above perhaps be moved there?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
