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
