- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 3 Feb 2001 16:55:24 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Fay, Chuck" <CFay@filenet.com> > ... 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). 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.) The alternative is either having no way for clients and servers that require that functionality to interoperate, or requiring that your server support something that you clearly don't want to support. If we are forced to chose between "requiring intermediate server state" and "disallowing intermediate server state", I can confidently predict that the consensus will be "requiring server state". If so, your server will have no way of advertising that it has any versioning support. Every other "baroque" option has exactly this characteristic ... there are a significant number of implementors that are depending on that option to achieve interoperability, but there are also several implementors that insist that they will not support that option, but do want to advertise that they support some other versioning capabilities. > 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. 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), but also allows you to have just one new header, instead of requiring a new header for every parameter to CHECKIN. 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. Well, that is a really catchy name (:-), but if we just add an Autoversion header for PUT, we can leave it as the "checkout option". So I have two questions: Chuck: Does the Autoversion header for PUT get you what you need? 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? Everyone else: Do you think that the Autoversion header for PUT is of sufficient value to be worth putting into core? It is a way for a versioning client to interact with a server like Chuck's without forcing his server to have every PUT to a version-controlled resource result in a new version. Cheers, Geoff
Received on Saturday, 3 February 2001 16:56:22 UTC