RE: Auto update of VCR when checking an associated working resource

One addendum: 
Explicitly point out that if the CHECKIN on the VCR fails, the client
would have to do a CHECKIN of the working resource followed by a MERGE
or UPDATE to retry the operation.

 


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Lisa 
> Dusseault
> Sent: Thursday, July 12, 2001 2:57 PM
> To: Jim Amsden; ietf-dav-versioning@w3.org
> Subject: RE: Auto update of VCR when checking an associated 
> working resource 
> 
> 
> I'm in favour of this.
> 
> One addendum:  if the server does NOT support the UPDATE 
> method, then the client MUST include the DAV:auto-update 
> property in the CHECKIN request.
> 
> lisa
> 
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> > Sent: Thursday, July 12, 2001 1:37 PM
> > To: ietf-dav-versioning@w3.org
> > Subject: Auto update of VCR when checking an associated working 
> > resource
> >
> >
> >
> > (sorry for the long, and perhaps confusing title)
> >
> > On the versioning teleconference call, 6/29/01, the participating 
> > working group members reached consensus on the following 
> approach to 
> > updating a version-controlled-resource on checkin of a working 
> > resource that was created by checking out the 
> > version-controlled-resource with DAV:apply-to-version.
> >
> > I would like get a sense if the rest of the working group 
> agrees with 
> > this proposal. I think it makes sense as the result of 
> checking out a 
> > VCR, modifying what you checked out, and checking it back in is the 
> > same regardless of where and how the state of the updated 
> resource was
> > managed,
> > on the client or on the server, with or without a working 
> resource. It
> > does mean changes to the spec, but this seems to be within the
> > boundary of
> > what's reasonable to do now. What do you think?
> >
> > Here's the proposal from the teleconference:
> >
> > When you apply CHECKOUT directly to a version URL, the semantics of 
> > the protocol are unchanged (so if you liked the old semantics and 
> > didn't want any auto-update on checkin, you would always apply 
> > CHECKOUT directly to a version URL
> >
> > When you apply CHECKOUT with a DAV:apply-to-version flag to 
> a VCR, you 
> > create a working resource whose DAV:checked-out version is the 
> > DAV:checked-in version of the VCR (as is required currently), but 
> > which now also has a protected DAV:auto-update property 
> which contains 
> > the URL of the VCR that was checked out.  (This requires one new 
> > postcondition for the CHECKOUT semantics in the working-resource 
> > feature).
> >
> > The MOVE operation is required to update the 
> DAV:auto-update property 
> > if the VCR is moved (or it can fail the MOVE), so the 
> DAV:auto-update 
> > property is always valid.  (This requires one new postcondition for 
> > the MOVE semantics in the working-resource feature).
> >
> > When you CHECKIN a working resource with a DAV:auto-update 
> property, 
> > the CHECKIN fails if the DAV:checked-out property of the working 
> > resource does not match the DAV:checked-in property of the 
> VCR. If the 
> > CHECKIN succeeds, the VCR identified by the DAV:auto-update 
> must have 
> > been updated to have the content and dead properties of the new 
> > version, and the DAV:checked-in version of the VCR must have been 
> > updated to identify the new version.  (This requires one new 
> > precondition and one new postcondition for the CHECKIN semantics in 
> > the working-resource feature).
> 
> 
>

Received on Thursday, 12 July 2001 18:40:13 UTC