RE: DeltaV doesn't support a true client workspace

See my proposal for CHECKOUT/CHECKIN enhancements below in support of a true
client workspace, along with interspersed responses to Geoff's reply.

> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thursday, January 18, 2001 10:05 AM
> To: ietf-dav-versioning@w3.org
> Subject: Re: DeltaV doesn't support a true client workspace
> 
>    From: "Fay, Chuck" <CFay@filenet.com>
> 
>    There seems to be an underlying assumption in DeltaV,
>    even for parts of core versioning, that the server
>    provides persistent storage of work-in-progress
>    on resources between checkout and checkin.
> 
> I don't believe that is the case.  As you point out below, core
> versioning allows a server to only support the DAV:when-unlocked
> mechanism, which creates a new version on every update.

Right, but it's still true that some of the key options, in particular
CHECKOUT, and even a core versioning feature like the DAV:when-locked flavor
of auto-versioning, make this underlying assumption.

>    Unfortunately, this assumption is not valid for some 
>    existing versioning systems, including a FileNET
>    content management product and one of the software
>    configuration management products we use internally.
>    These two versioning systems employ the concept of
>    what I would call a *real* client workspace, where
>    *all* intermediate work-in-progress is stored on the
>    client side between checkout and checkin...
> 
> That's OK.  Although the protocol defines how a client interoperates
> with a server that provides storage for intermediate work-in-progress,
> a variety of the options (e.g. baselines and activities) should work
> just fine for a server that does not support intermediate 
> work-in-progress.

Okay, but wouldn't it be better if a key option like CHECKOUT worked as
well?

>    One alternative is to build a core versioning layer for 
>    these two systems which would disallow the
>    DAV:when-locked flavor of DAV:auto-version.
> 
> That is already legal in the current core versioning definition.

Right.

>    But this would result in a new version for every
>    PUT or PROPPATCH of dead properties done by the
>    client.  Arbitrary DeltaV clients are not likely to
>    limit themselves to one PUT between a LOCK and
>    UNLOCK, so there would likely be a proliferation
>    of unwanted intermediate versions.  Scratch that
>    alternative.
> 
> Well, there is not much you can do about making a client that requires
> intermediate storage on the server (perhaps because it has none of its
> own) to interoperate with a server that does not provide intermediate
> storage.  That's the same for many of the other options (i.e. they are
> server options because clients want the servers to do that work).

Yes, but my point is to allow a client that is willing to accommodate a
server with no support for intermediate storage.  Sure, clients that depend
on features not supported by a particular server won't work with that
server.  (As an aside, that's the danger of having lots of options that
won't necessarily be supported by all the server implementations.  That's my
main concern with the baroque set of options currently in DeltaV.)

Skipping to the third alternative...

>    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.
> 
> The only way that would help you is if we *required* this to be the
> only way a client could interoperate with a versioning server.  That
> would make the versioning protocol useless for a client that does
> not have local persistent storage, so I find it very unlikely that
> many would find this acceptable.

I disagree.  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.  Clients depending on working
resources or checked-out mutable VCRs could choose not to supply a CHECKIN
body and would work just fine with servers supporting those optional
features.  As always, independent of this proposed change, they would fail
to work with servers implementing only core versioning.

Besides the change to CHECKIN, clients will need a means to determine if the
server supports storage of intermediate state.  I propose creating a new
option called "Mutable Checked-out Version-Controlled Resource Option" to
replace the current CHECKOUT option.  Mutable checked-out VCRs would be
defined to accept PUTs and PROPPATCHes between checkout and checkin and
persistently store the resulting modifications during that period.  CHECKOUT
(and CHECKIN as modified here) would move back into core versioning, but
would not support mutable checked-out VCRs without the mutable checked-out
VCR option.  Thus any client storing all intermediate state locally and
using this CHECKIN feature would work with any server supporting core
versioning.

(Aside:  I'm not proposing a solution for checking in changes to dead
properties coincident with content changes on a CHECKIN, but I suppose that
could be done with a structured request body with both properties in
PROPPATCH form and content in PUT form.  That's not a priority, though,
because the systems I'm familiar with don't support dead properties.)

>    Are there other alternative solutions to this problem?
> 
> If the problem is "how to make a client interoperate with a server
> that does not provide the functionality required by that client",
> then I don't think there are *any* solutions to this problem.

Can't disagree with the conclusion, but I'm not trying to solve that
particular problem (:-).  I would say the problem is "how to make DeltaV fit
existing practice better, in the area of products that don't provide for
server-side storage of intermediate state between checkout and checkin".

>    Do others on the mailing list know of existing
>    versioning systems with this same problem with
>    DeltaV?  Or is this problem limited to just
>    these two systems?

I'm still interested in hearing about other versioning servers that don't
support intermediate storage of work-in-progress on checked-out objects.  I
suspect this is a common trait of existing versioning systems.

--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, 2 February 2001 20:25:19 UTC