RE: CHECKIN to update a VCR ...

   From: John Hall [mailto:johnhall@evergo.net]

   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.

Note that the revised proposal no longer allows the client to do so
(it is a protected property, maintained by the server).

   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.).

Yes, one of the reasons to make it a server-maintained protected
property is to avoid these error cases.  It also prevents interoperability
problems when some servers let you play with the value, and others
don't.

   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'd go even farther ... you cannot modify or delete the property
(i.e. it is protected).  You can of course delete the working resource
if you are no longer interested in it.

   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.

One reason I'd rather not have it on the CHECKIN is that this
reintroduces the error cases (i.e. the specified URL is not a VCR, the
working resource is not checked-out from a version in the version
history of the VCR, etc.)

   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.

Yup.

   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).

A server could do this (a client needs to be prepared for the
MOVE to fail because of locking or whatever anyway), but I wouldn't
hightlight this possibility in the protocol (e.g. by giving it
its own error code).

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

I'd get rid of the "may be removed by a client".  Don't see any
compelling benefit, and it is simpler to just make the property protected
(we have no "cannot change but can delete" properties as of yet).

   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.

Yup.

   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.)

I feel the same way about this as the "disallow move" case.
A server can do this, and a client will need to handle the
CHECKIN failing in any case (for locking reasons, for example),
but I wouldn't want to hightlight this in the protocol by
giving it its own error token).

Just for interests sake, is anyone other than Tim against this
set of semantics?  My current inclination is to leave the spec
alone if there is even a single "strong" objection to a change,
so Tim's objection is sufficient, but I was wondering if there
are any versioning server implementors out there which actually
would have a problem implementing the "move tracking" behavior.

Cheers,
Geoff

Received on Friday, 22 June 2001 15:02:31 UTC