- From: Fay, Chuck <CFay@filenet.com>
- Date: Wed, 17 Jan 2001 12:05:58 -0800
- 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 alternative. 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 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 Wednesday, 17 January 2001 15:17:27 UTC