RE: Last Call for DAV:checked-out-vcr Proposal

> We're getting all tar-babied up just to save a round trip.

No, you are supporting smaller subset servers (like mine) in addition to
saving a round trip.  If you wish to have servers track the location of
the VCR in order to provide this, then I'm all for it.  I've already
added a field in my database just to track the new value and allow
clients to write illegal values there.  (I'll take it out if you say I
can protect the value from such abuse, since I can infer the valid
information).

Look at it from the opposite end of the spectrum.  From my point of
view, I'm trying to un-tar-baby this part of the spec.  Working
resources?  Sure that is useful.  UPDATE, don't need it.  MERGE, don't
need it. 'Versioning' of the working resource, don't need it.

You say that your implementation makes it hard to make CHECKIN/UPDATE
atomic.  On my system, they are naturally atomic.  That is why I want
the atomic operation offered.

It might be easier if you reversed the nomenclature.  If instead of
CHECKIN/UDPATE you thought in terms of UPDATE/CHECKIN the problems would
probably fall out.  In UPDATE/CHECKIN the UPDATE does a 'new version on
the working resource' which would be optional for a server to allow and
the CHECKIN then retains its natural meaning (like it has when you
CHECKIN an in-place-checkout).

I realize that it is probably too late to reverse that nomenclature.

It comes back to 1) working resources are cool 2) an atomic operation
makes sense for a wide selection of clients demonstrated by the fact it
is often the only option offered and 3) it is very, very, important to
me.

Received on Thursday, 21 June 2001 00:18:50 UTC