RE: Comments on bind-08

Julian writes:

> >>>* Section 4. Need a new condition to cover the case where the BIND 
> >>>half-succeeded, and then needed to be rewound. This 
> condition would 
> >>>address the case where Overwrite is true, the destination
> >>
> >>binding has
> >>
> >>>been removed, but the new binding couldn't be created.
> >>
> >>But then it wouldn't be atomic, right?
> > 
> > 
> > Well, what status element would you return in the case where the 
> > method half-succeeded, and then needed to re rewound?
> 
> That depends on why the new binding couldn't be created....?

Say, for the sake of argument, that there is a disk full condition, such
that the database holding bindings could delete a binding, but couldn't
create the new binding. In this internal server error condition, what status
code/element would be returned?

> I'm not seeing a problem (yet). C1 would be removed, while C2 
> wouldn't. 
> It's the server's job to ensure that resource R isn't 
> negatively affected.

OK, I'll let this one go.

> Could you be more specific about which case you think would 
> need to be clarified? Is this about the specific marshalling 
> of REBIND, or about locking semantics in face of multiple bindings?

It's about the problems clients have with correctly marshalling needed
information into the If header.


> It's way "everybody" does it (WebDAV lock tokens, WebDAV 
> ordering, Atom IDs, XML namespaces). Also, UUIDs may not 
> always be the best identifier available. For instance, for 
> lock tokens a server may be using a single UUID + a counter 
> (as allowed in the opaquelockoken syntax) -- why shouldn't it 
> do the same for resource IDs?

OK, I'll let this one go.

- Jim

Received on Wednesday, 1 December 2004 20:03:30 UTC