- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 18 Jan 2001 13:04:36 -0500 (EST)
- To: ietf-dav-versioning@w3.org
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. This is explicit in the optional VCR CHECKOUT-CHECKIN semantics, and in the Working Resource option. Many of the options are not supported by certain classes of servers, but that doesn't mean those classes of servers violate underlying assumptions of DeltaV. 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. Yes, but the protocol explicitly states that a client should be aware that a server may not allow change to the DAV:auto-version values, which means that a server that only supports DAV:when-unlocked is fully compliant, and should interoperate with core versioning clients. 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. 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. 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.) I agree. 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. 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). 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. That's your only choice if you want your server to interoperate with clients that assume functionality that your server does not currently provide. 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. 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. 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? Any server that only provides a subset of the defined functionality will only support the subset of clients that only use that subset. This is a problem for any server, but it is a logically unavoidable one. Cheers, Geoff
Received on Thursday, 18 January 2001 13:05:49 UTC