Hello!
I have the following situation:
* engine prepares data, returns STEPCMD_SENDDATA
* client sends data, calls engine with STEPCMD_SENTDATA, engine
replies with STEPCMD_NEEDDATA
* transport is called, replies with "data not ready yet", engine
is called again with STEPCMD_SENTDATA => error, in state
ces_needdata (syncclient.cpp TSyncClient::SessionStep) this step
isn't handled, leading to a return error code
I could change our loop so that the transport is called again
immediately instead of going through the engine. However, it looks
better to give the engine a chance to react. Therefore I suggest to
accept STEPCMD_SENTDATA in the ces_needdata state like this:
diff --git a/src/sysync/syncclient.cpp b/src/sysync/syncclient.cpp
index 79f4692..e26c7ee 100755
--- a/src/sysync/syncclient.cpp
+++ b/src/sysync/syncclient.cpp
@@ -455,6 +455,11 @@ TSyError TSyncClient::SessionStep(uInt16 &aStepCmd,
TEngineProgressInfo *aInfoP)
OBJ_PROGRESS_EVENT(getSyncAppBase(),pev_sendstart,NULL,0,0,0);
sta = LOCERR_OK;
break;
+ case STEPCMD_SENTDATA :
+ // no state change, keep asking for the data
+ aStepCmd = STEPCMD_NEEDDATA;
+ sta = LOCERR_OK;
+ break;
} // switch stepCmdIn for ces_needdata
break;
We didn't run into this situation before, although the code was there,
because our traditional HTTP transports didn't return prematurely. Now I
have added a transport for the D-Bus API which does that. The patch
solves the problem for me. Any comments?
--
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.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
