W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

DeltaV doesn't support a true client workspace

From: Fay, Chuck <CFay@filenet.com>
Date: Wed, 17 Jan 2001 12:05:58 -0800
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F05B22960@hq-expo2.filenet.com>
To: ietf-dav-versioning@w3.org
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.  This is explicit in the optional
VCR CHECKOUT-CHECKIN semantics, and in the Working Resource option.  It is
also implicit in core versioning when DAV:auto-version is set to
DAV:when-locked:  between the LOCK and UNLOCK, the server is expected to
provide persistent working storage for intermediate updates via PUTs and
PROPPATCHes from the client.

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.  A user may choose to store
work-in-progress on a file server for backup or access from other clients,
but in any case the versioning server software does not provide any
persistent work-in-progress storage.

So DeltaV is not a great fit for these two existing systems.  (I won't argue
that their reliance on a client workspace is necessarily a better design
than DeltaV's server workspace.  Rather, I raise it as existing practice
that needs to be considered by DeltaV.)

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.  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

Another alternative would be to build a work-in-progress persistence layer
on top of these existing systems to accommodate DeltaV, but that is a costly
and awkward choice.

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.

Are there other alternative solutions to this problem?

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

--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 Wednesday, 17 January 2001 15:17:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC