RE: Issue: COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION

<<
Of course, as with most questions of re-use, it is a value
judgement as to "how close" two concepts are to each other,
and how likely it is for them to evolve in divergent ways.
>>
Well let's go in to a few examples and see if that sways any
opinions.

To review...

The basic concept of the proposal is that the body of the
COPY/MOVE multistatus response will list source resources
rather than destination resource.  But additionally, it
can list resouces that contributed to the status as an
explanation of the source resource(s) error status.  Often
that will be a destination resource.

Now for some examples...

A depth lock above the destination that prevents a COPY/MOVE
to the destination.  How would you list this?  (I'll let Geoff
and Julian make the proposals.)

A lock on the parent collection of the destination resource.

A lock on the destination resource.

A lock below the destination resource whose protected-lock-uri
guarantees prevents the destination DELETE phase of the MOVE/COPY
from occuring.

A COPY/MOVE to a destination that doesn't have an immediate parent.

A depth lock above the source URI that prevents a MOVE.

A lock of the parent of the source URI prevents a MOVE.

A lock on the source prevents a MOVE.

A lock below the source prevents a MOVE due to protected-lock-uri
guarantees.

Same as the above LOCK situations but ACL's instead.

Can the two approaches handle all of these well?

Reminder, the issue is just for MOVE/COPY lock issues, but
a check of these will let us know if the mechanism is flexible.

J.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com

Received on Tuesday, 7 May 2002 11:20:21 UTC