Hello Patrick, On Mar 6, 2010, at 7:10 , Patrick Ohly wrote:
> 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) Yes, the backend should return a 404. 500 is considered fatal and completely unspecific and will abort any session. > 7. 10500 is sent to server > 8. server shuts down session *without* reply Hm, I'd expect a reply here, too. Would need to analyze logs in detail to find out why it does not here. > 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). No. The 10000 offset is something internal to the engine. The plugins should return 3-digit SyncML error codes or in some special cases 20xxx ones. All plugin errors are local anyway. > 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. As plugin errors are local by definition, we could make the calling code more robust against plugins adding the 10xxx offset, so if you have routines used in plugins and outside, they could both use 10xxx. > Client and server don't agree on whether the session should continue > (steps 8 and 9). Not sure who is right here. Basically, the server should send a response for every request, so that's probably a bug. Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
