CHECKIN to update a VCR ...

First, to reiterate, this is a very important feature to me (CHECKIN of
working copy to update a VCR).  I'm willing to accept almost any
solution that accomplishes that goal.  Note that on my server this is
the only CHECKIN of a working copy that is allowed.  

I thought that Geoff's proposal to have the VCR address be updated in
the CHECKIN to be quite sensible, and I didn't mind tracking the VCR
even if it was moved.  Probably because that was easy for my
implementation to do.

However, Geoff's proposal said that I had to let the client modify the
contents of this property.  That means that I have to deal with the case
where the client specifies a bad value (I need an error either on the
PROPFIND or the CHECKIN.  If I prohibit the bad value from being set the
error is on PROPFIND.  If the bad value is set, then an error may occur
on the CHECKIN and update VCR where it won't work.).

If I had written the proposal, I'd have made the new property
"apply-to-VCR" removable but not client modifiable.  That way everyone
knows that the field either exists and is valid or doesn't exist.

I would also have considered having the element apply-to-version sent on
the CHECKIN rather than the CHECKOUT (which means "apply-to-VCR" would
always be set).  But that is a nit.  I'm happy with it on the CHECKOUT.

So my full proposal, based on Geoff's, would be:

CHECKOUT postcondition:
If CHECKOUT is sent with the "apply-to-version" element, then the
working copy will have "apply-to-VCR href-of-VCR" set.

If "apply-to-VCR" is set, then this field will be updated if the VCR is
moved.  (You could let the server refuse to move such a VCR but I'm
assuming that is a non-starter).

"apply-to-VCR" may be removed by a client, but not modified.

CHECKIN poscondition:
A CHECKIN of a working copy with the "apply-to-VCR" property set will
update the VCR associated with the working copy.  If this isn't
possible, an error "FILL-IN-HERE" is generated if this isn't possible.

A CHECKIN of a working copy without "apply-to-VCR" set when the working
copy can not be used to update a VCR will fail with the error
"DAV:update-of-vcr-impossible".  (Well, I thought I'd ask.  Our server
will fail such a checkin.  The only question is the error code that gets
kicked back.)




> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Wednesday, June 20, 2001 7:25 AM
> To: 'DeltaV (E-mail)'
> Subject: RE: Last Call for DAV:checked-out-vcr Proposal
> 
> 
> If we are going to add a protocol element for allowing a 
> CHECKIN of a working resource to update a VCR, it would seem 
> appropriate to define this in a way that is friendly to 
> clients (i.e. they are not required to "LOCK" the VCR 
> namespace, and they are not at risk of being told "sorry, 
> that VCR you wanted to update is somewhere else, but I won't 
> tell you where".
> 
> I don't buy the "hard to implement" argument, since anyone 
> who is implementing a distributed versioning system will have 
> to deal with far more difficult implementation issues than 
> reliably associating working resources with 
> version-controlled resources.  And for the common case (where 
> the working resources and the version-controlled resources 
> are on the same server), it is not hard for the *server* to 
> track these moves, but it is very hard for the *client* to 
> track these moves, which is why the server should be required 
> to do so.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Tim Ellison [mailto:tim@peir.com]
> Sent: Wednesday, June 20, 2001 9:46 AM
> To: 'DeltaV (E-mail)'
> Subject: RE: Last Call for DAV:checked-out-vcr Proposal
> 
> 
> John Hall wrote:
> > In my system I have no problem tracking moves, but it isn't my 
> > objective.  My objective is having a CHECKIN of the working 
> resource 
> > update the VCR.  That isn't a 'gee it would be nice to 
> have' request. 
> > It is far more important to me than that.  Lack of such a feature 
> > would be quite painful.
> 
> I think you may have said this already, so apologies if you 
> did.  Instead of a new property on a working resource that 
> tracks MOVEs (which I think will be hard to implement on 
> distributed systems), how about a new CHECKIN option to do 
> the checkin and version-controlled resource update atomically 
> with a specific error condition if either cannot be achieved?
> 
> I'd be happier with that.
> 
> Tim
> 
>

Received on Wednesday, 20 June 2001 14:20:27 UTC