Re: [SyncEvolution] [os-libsynthesis] super data store: trying to read to check for existance
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
luz(a)plan44.ch - www.plan44.ch