RE: DeltaV doesn't support a true client workspace

From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
>    From: "Fay, Chuck" <CFay@filenet.com>
>    >    A third alternative would be to add a flavor of 
>    >    CHECKOUT-CHECKIN to core versioning in DeltaV
>    >    that allows all changes to accompany the CHECKIN
>    >    method.  This is the model used by the existing
>    >    systems I mentioned.
> 
>    Let's say that we shifted the keep-checked-out option from the
>    CHECKIN request body to a header, and instead allowed an optional
>    CHECKIN request body containing new contents for the resource.
>    That is, the optional request body would be the same as a PUT
>    request body.  That allows a client that is storing all
>    intermediate state locally to do a single checkin with the new
>    content bundled with the CHECKIN request.  This would not force all
>    clients to do so, however.
> 
> Currently, the protocol already provides an interoperable way of
> achieving this result with the PUT method applied to a
> version-controlled resource with DAV:auto-version set to
> DAV:when-unlocked.  
> 
> Perhaps your intent here is to provide a way for a client to get
> auto-version behavior from PUT only when it explicitly asks for it?
> I.e. you only want clients to create new versions if they know
> that they are doing so?  If so, I believe a simpler way to
> achieve your goal would be to add an Autoversion header to PUT.
> This would tell PUT to have autoversioning behavior for just
> that request.

I see no value in an Autoversion header on PUT.  Clients that are not
auto-versioning-aware would not use such a header by definition.  If a
client is auto-versioning-aware, it doesn't need a special header on PUT to
get auto-version behavior only when it explicitly asks for it.  It would
simply choose to do a single PUT with all its changes, rather than multiple
PUTS along the way.

> This not only is far more consistent with the current pre-conditions
> of CHECKIN (i.e. that it is only applied to a checked-out resource),

I don't follow you here.  My proposal is to move the CHECKOUT option back
into core versioning, so both CHECKOUT and CHECKIN would be in core
versioning.  The pre-condition on CHECKIN would still be enforced.  That is,
CHECKIN would only be allowed on a checked-out resource that was checked out
with ... you guessed it ... CHECKOUT.  So I don't see the inconsistency you
suggest.

> but also allows you to have just one new header, instead of requiring
> a new header for every parameter to CHECKIN.
> 
> So I have two questions:
> 
> Chuck: Does the Autoversion header for PUT get you what you need?

No (see above).  To reiterate briefly, I'm trying to avoid a proliferation
of versions created by auto-versioning.  My server would auto-version only
for versioning-unaware clients.  Versioning-aware clients would CHECKOUT,
GET, do all modifications locally on the client, then CHECKIN with the new
content as the CHECKIN request body.  What could be simpler?  I strongly
urge that this model of use be supported by DeltaV.  Note that my server
would reject any PUTS on a checked-out VCR, because it would not implement
my proposed mutable VCR option.

> Note that to be interoperable with versioning unaware clients,
> you'll have to set DAV:auto-version anyway, so are you sure 
> that existing DAV:auto-version and PUT behavior isn't sufficient?

Yes, because of the problem of proliferating versions.

--Chuck Fay 
FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com

Received on Friday, 9 February 2001 12:14:51 UTC