24 Mar 2004 02:32
Re: DAV:unreserved - missing precondition?
Geoffrey M Clemm <geoffrey.clemm <at> us.ibm.com>
2004-03-24 01:32:33 GMT
2004-03-24 01:32:33 GMT
We could make this change for JSR-147 (and I will do so), but for backward compatibility, we should leave the name of this precondition alone for RFC-3253. Cheers, Geoff Alison wrote on 03/22/2004 09:12:25 AM: > Would it also be clearer if the precondition: > > DAV:one-checkout-per-activity-per-history > > was renamed to > > DAV:one-reserved-checkout-per-activity-per-history? > > Geoffrey M Clemm wrote: > OK, that makes sense to me. > > I'll make this update to both RFC-3253bis as well as JSR-147, > if there are no objections. > > Alison wrote on 03/22/2004 06:46:49 AM: > > > The second option looks better to me, i.e. > - disallow the checkin of an unreserved checkout if there is a > reserved checkout > > as I think the first condition would need to be: > > - disallow a reserved checkout if there is already an unreserved > checkout, and disallow an unreserved checkout if there is already a > reserved checkout. > > which restricts parallel development. > > Alison. > > > > Geoffrey M Clemm wrote: > I believe the point of a reserved checkout was to ensure that the > checkin would succeed. But if we allow a reserved checkout to succeed > when there are currently unreserved checkouts against that activity, > if any of the unreserved checkouts are checked in, the subsequent > checkin of the reserved checkout will fail. > > So doesn't that imply we should either: > - disallow a reserved checkout if there is already an unreserved > > checkout > > or > - disallow the checkin of an unreserved checkout if there is a reserved > checkout > ? > > Cheers, > Geoff > > Alison wrote on 03/18/2004 08:08:27 AM: > > > The 13.3.1 description of DAV:unreserved is more restrictive than > DAV:one-checkout-per-activity-per-history enforces. The description > only allows for one checked-out resource for the activity, if that > checked-out resource has DAV:unreserved false. The precondition > however allows for multiple checked-out resources for the activity, > where at most one of these has a DAV:unreserved property of false. > > Given existing implementations of 3253 which may only enforce the > precondition rather than the description, I would suggest that the > description of DAV:unreserved is lined up with the precondition. > That is, at most one reserved (DAV:unreserved false) checked out > resource for an activity, but any number of unreserved (DAV: > unreserved true) checked out resources for the same activity. > > Geoffrey M Clemm wrote: > Either interpretation is OK with me. Do you (or anyone else) want > this to be added? > > Alison wrote on 03/12/2004 01:04:43 PM: > > Section 13.3.1 of the spec says: > > > 13.3.1 DAV:unreserved > This property of a checked-out resource indicates whether the > DAV:activity-set of another checked-out resource associated with the > version history of this version-controlled resource can have an > activity that is in the DAV:activity-set property of this checked-out > resource. > > The activity feature adds a checkout precondition: > > > (DAV:one-checkout-per-activity-per-history): If there is a request > activity set, unless DAV:unreserved is specified, another checkout > from a version of that version history MUST NOT select an activity in > that activity set. > > Should this precondition also cover the case where the checkout request > includes an activity and specifies DAV:unreserved, but the checkout > should fail because a checked-out resource already exists, with > DAV:unreserved false, and a DAV:activity-set value that contains the > checkout request activity? > > > > > > > > >