Hello Patrick, On Oct 25, 2011, at 9:36 , Patrick Ohly wrote:
> Are these expectations documented somewhere? Probably not as clearly as it should be. Beat's doc/SDK_manual.pdf is all we have. > I'm still a bit fuzzy about > which error codes are expected. For example, should a delete of a > non-existent item succeed (200) or fail (404)? It should return 404. The basic rule is: at the API level, the errors should be as direct and "honest" as possible. If the engine tries to delete something that does not exist, the plugin should return an error. It's the task of the engine to disguise that error towards the SyncML peer (and in fact, there is an option for that: <deletinggoneok>, on by default, which means that failed deletes don't show up as 404 towards the peer, but go through as 200/OK). >> Still, if a plugin would not conform to that in its implementation of >> delete, that would probably have gone unnoticed so far. > > Right. SyncEvolution has hardly ever (never?) returned 404 and that has > not been an issue until now ;-) Because <deletinggoneok> is on by default, it made no difference. However (and that's the reason for that expensive test in the first place and the config option), the SCTS (SyncML Conformance Test Suite) did a test which failed when deleting a non-existing item returned 200. As in the SyncFest's back in early 2000s passing SCTS was a prerequiste to be allowed to go to the IOT, the demands of SCTS had to be met even if the opposite made more sense for real world operation... >> Of course, the test is a bit expensive - if that's a concern, one >> could differentiate between plugin datastores and others (all the >> builtin ones, including SQL/ODBC), and use the expensive read test >> only for the latter. Like a virtual dsDeleteDetectsItemPresence() >> which returns false by default, but can be overridden in plugin >> datastores to return true. > > That sounds like the right compromise. I'm much more comfortable > returning 404 in a delete and not reporting that to the user as an > error, compared to not reporting a 404 in a ReadItem call (as I have to > do now). Now I don't understand. Why do you have to *not* report a 404 in ReadItem now?? Best Regards, Lukas Zeller, plan44.ch [email protected] - www.plan44.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
