CHECKIN / CHECKOUT proposal from Geoff

I think something like this would be highly desireable.  It removes the
dependency on UPDATE/MERGE, it makes the meaning of CHECKIN on a working
resource with this flag the same as a CHECKIN on a edit-in-place
resource, and it simplifies the life of simple clients / servers
greatly.  

Not supporting working copies and instead giving people
'checkout-in-place' introduced the unwanted side effect of exposing
users to works in progress.

As I understand it then, the language goes something like this:
DAV:apply-to-version  -- If this property is present, a CHECKOUT of a
WORKING COPY on the VCR will set the property checked-out-VCR on the
working copy.  An implementation MAY support this feature.  An
implementation MAY allow this property to be changed.  An implementation
that supports this property, the feature WORKING COPY, but not the
features UPDATE or MERGE, SHOULD prevent this property from being
modified.

<!ELEMENT apply-to-version EMPTY>

DAV:checked-out-VCR

If this optional property exists on a working copy, then a CHECKIN will
also update the VCR listed.  An implementation MUST support this
property if it supports WORKING COPY but not one of (UPDATE, MERGE).

<!ELEMENT checked-out-VCR (href)>

CHECKIN postcondition:

If the property checked-out-VCR is present, then a CHECKIN will
automatically update the VCR to reflect the content and dead properties
of this version.

> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Friday, June 15, 2001 7:51 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Question on Checking (of Working Resource vs. 
> VCR): is this r ight?
> 
> 
>    From: Lisa Dusseault [mailto:lisa@xythos.com]
> 
>    We might also consider trying to remove the dependency [of the
>    working-resource option on the update option], since one would
>    think that in a non-forking server, a CHECKIN would 99% of the time
>    be followed by a UPDATE to push the latest content to the VCR.
>    Rolling those two actions into one request (unless specified
>    otherwise) would save a round-trip, because the CHECKIN and UPDATE
>    can't be pipelined if you have to wait for the successful response
>    to the CHECKIN before knowing how to send the UPDATE.
> 
> If folks agree that this is worth making an addition to the 
> protocol to support, I'd suggest the fillowing:
> 
> Add a property to a working resource like 
> "DAV:checked-out-VCR".  Set this property on the working 
> resource created when a CHECKOUT is applied to a VCR with the 
> DAV:apply-to-version option.  A client is of course free to 
> add/delete/change this property.  Then add a postcondition to 
> "CHECKIN" that says that if there is a DAV:checked-out-VCR on 
> the working resource being checked in, the specified VCR will 
> automatically be updated to reflect the content and dead 
> properties of that version.
> 
> And I will also point out that we would then have a live 
> property that would distinguish a working resource from a 
> checked-out version-controlled resource ... (and thus remove 
> one of the objections of using 
> DAV:supported-live-property-set to classify versioning 
> resources ... I can sense Tim either smiling widely, or 
> groaning loudly, or both :-).
> 
> Cheers,
> Geoff
> 
>

Received on Friday, 15 June 2001 14:38:55 UTC