Hello! Another resume problem, probably caused by SyncEvolution: 1. item deleted on server 2. <Delete> sent to client 3. client processes it, its next message to server gets lost 4. client and server suspend 5. after resume, <Delete> is sent again 6. client backend returns 10500 in DeleteItem (sysync::LOCAL_STATUS_CODE + 500) 7. 10500 is sent to server 8. server shuts down session *without* reply 9. client encounters network problem due to missing reply
The client should not treat removal of an already removed item as error. This happens here because I was using the file backend, not the Evolution backends, which already work like that (step 6). I suppose I'm still a bit uncertain about local status codes. Is the plugin allowed to return an error marked as local to the Synthesis engine? If yes, then the engine should have sent 500 to the server, not 10500 (step 7). If no, then I need to be more careful in the exception handling code which creates the status code. If the consumer of the status is the engine, we must not mark the error as local. If the consumer is SyncEvolution above the engine, then they should be marked as local, just as if they came out of the engine. Client and server don't agree on whether the session should continue (steps 8 and 9). Not sure who is right here. -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis