RE: Working Resource Issues ...

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

   ... In the post conditions for 9.3
   create-working-resource-from-checked-in-version the spec states
   that "... the version-controlled resource remains checked-in."

   That is why you have seen two operations when I've only seen one, and
   need an UPDATE or MERGE.  Meanwhile, I'm going "of COURSE the VCR is
   checked out.  I got a successful return on my CHECKOUT didn't I?"  I
   think you should create a new verb (MKWORKING), personally.

We did discuss having two verbs a long time ago, but it seemed
unnecessary (and it would raise the issue of which verb was called
CHECKOUT, and therefore represented the *real* checkout :-).

   So how about leaving the WORKING-RESOURCE definition as-is and modify
   the CHECKOUT-IN-PLACE feature to make invisibility to other users a
   (REQUIRED) option?

The whole point of CHECKOUT-IN-PLACE is to make the modifiable
resource visible at the original URL, so that references to that
resource see the intermediate states.  So we'd have to supplement
the existing functionality, not replace it, and an addition of this
kind would need a compelling use case behind it.

   I think you will have to finesse a much smaller
   number of issues if you do that.  Since it is required, it doesn't raise
   the issue of client interoperability.  It is new functionality; you
   can't do what I need to do with the spec defined as is.  And by moving
   it down there you don't confuse the complex 'package' issues Geoff
   raised.  You put it in the basic package, and you don't have clients
   trying to figure out why they have WORKING-RESOURCE provided but not
   UPDATE or MERGE.

Currently clients don't have to figure out why they have
working-resource provided but not update, because there is no defined
package that has working-resource but not update.

On the other hand, I am sympathetic to servers that do not want to
support update (heck, I tried to get rid of the update feature
all together :-), which is why I think it is worth pursuing this
thread.  But keep in mind that the protocol has already passed
last working group call, and is in the hands of the area director,
so it would need to be a really glaring flaw for us to add/change
the protocol at this point (deletion is still fair game, though).

   4.1.3  DAV:checkout-invisible

   Normally, edits made on a resource while checked out are visible to
   other users.  If checkout-invisible is specified, however, other users
   will only see the last checked-in version.  A client is encouraged to
   see this feature as "lite" version of WORKING-RESOURCE which leaves the
   VCR in the checked-out state.

How do users see "their" checkouts?  We don't want to tie the
versioning protocol to some kind of authentication mechanism.

   4.2 CHECKOUT Marshalling:

   If the element checkout-invisible is present, the response MUST include
   a Location header.

   4.6: Additional PUT / PROPPATCH semantics.

   If a Location header was returned with the CHECKOUT, the URL specified
   in the Location header MUST be used for PUT and PROPPATCH requests.
   Otherwise, the server will return
   cannot-modify-version-controlled-content.

   4.7: Additional DELETE semantics.

   A delete on the URL returned by a CHECKOUT Location header will undo the
   CHECKOUT which created it.

You'd have to also define how every other HTTP method acts against
these "invisible" resources.  What about MOVE, LOCK, COPY?  (This
would make even lock-null resources look good in comparison :-).

Cheers,
Geoff

Received on Thursday, 21 June 2001 17:17:24 UTC