RE: Review of ordering draft, version 05

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   > But without an explicit declaration of atomicity, a failure might
   > indicate "partial success" (i.e. some of the postconditions were
   > produced).

   Well, in the case of an internal server error, obviously this may
   happen.  There are simply kinds of errors that are outside the
   control of the WebDAV code handler, such as database connections
   going down, file system corruption, manual operator intervention
   and so on... So even if the spec mandates atomicity, a client
   really can't reliably assume what specifically went wrong when he
   gets a 500 status, right?

That's where the separate post-conditions come in handy.  A server
can return all the post-conditions that failed in the DAV:error node,
which gives the client an indication of what kind of things failed.

   >    The ordering spec uses the same structure as RFC3253 here, and
   >    RFC3253 doesn't seem to use the term "atomic" anywhere when
   >    specifying multiple postconditions. So if this really is an issue,
   >    I think it applies to all specs using this terminology, not only
   >    the ordering spec.
   >
   > There were various debates about what "atomic" means, so the
terminology
   > used in RFC3253 to indicate atomicity is:
   >
   > "If an XXX request fails, the server state preceding the request MUST
   >  be restored."

   I see. So I'd propose to simply add this very sentence to the ORDERPATCH
   method description in the final editing pass.

Works for me.

   Are we done now? :-)

I hope so (:-).

   P.S.: why doesn't the BIND spec include this magic sentence? Just because
   there's only a single postcondition defined for BIND?

Yup.

Cheers,
Geoff

Received on Thursday, 27 February 2003 08:47:01 UTC