FW: DeltaV doesn't support a true client workspace

[Reformatted the first part of the message below for readability.  I hope
this one makes it through the mail servers in better shape.  --Chuck]

-----Original Message-----
From: Fay, Chuck [mailto:CFay@filenet.com]
Sent: Friday, February 09, 2001 9:10 AM
To: Geoffrey M. Clemm; ietf-dav-versioning@w3.org
Subject: 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 14:06:50 UTC