- From: Fay, Chuck <CFay@filenet.com>
- Date: Fri, 9 Feb 2001 16:26:32 -0800
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, ietf-dav-versioning@w3.org
Reformatted one last time -- if this doesn't get through cleanly, you'll have to parse it on your own (:-). Sorry for the noise... To make it worthwhile, I've included more on the proposal in this copy: I noticed that I didn't reiterate all the key points in my message below, so let me elaborate here. Assume that my versioning server does not allow mutable non-collection resources of any kind -- every PUT MUST create a new version. So it offers no storage of intermediate resource state between a checkout and checkin. I'm proposing that the ability to do PUTs to a checked-out VCR remain an option. That capability is currently embedded in the CHECKOUT option. I want to separate that capability out and keep it optional. I want to return the CHECKOUT, CHECKIN, and UNCHECKOUT methods to core versioning, but without the mutable checked-out VCR capability. Thus a core versioning client could do the following (assume all non-collection versionable resources are version-controlled): CHECKOUT /foo.html GET /foo.html Modify content locally, saving intermediate state locally or on a file server, but not by doing a PUT to /foo.html, which is not allowed in my proposal. PUTs would not be allowed on checked-out VCRs in core versioning. (Note that PUTs would always be allowed on checked-in VCRs with auto-version set to either always-checkout-* value.) Finally I'm happy with my local copy and want to create a new version on the server with my local content. CHECKIN /foo.html (with new content in the request body) I don't see why there should any big objection to this proposal, except on religious grounds that any real versioning server *must* provide intermediate storage of working versions. Clients that can't live without intermediate storage on their versioning server can still take advantage of servers offering that option and don't have to include a request body with the CHECKIN. They just won't work with my server and I can accept that. If all clients end up requiring that, I'll end up changing my server. But it works fine for many customers today without that capability. This allows CHECKOUT/CHECKIN methods in core versioning, which seems intuitively necessary. What kind of versioning server doesn't have the notion of CHECKOUT and CHECKIN? It seems unimaginable that core versioning could be defined without including these methods. --Chuck -----Original Message----- From: Fay, Chuck Sent: Friday, February 09, 2001 11:09 AM To: Geoffrey M. Clemm; ietf-dav-versioning@w3.org Subject: FW: DeltaV doesn't support a true client workspace [Reformatted the first part of the message below for readability. I hope this one makes it through the mail servers in better shape. --Chuck] -----Original Message----- From: Fay, Chuck [mailto:CFay@filenet.com] Sent: Friday, February 09, 2001 9:10 AM To: Geoffrey M. Clemm; ietf-dav-versioning@w3.org Subject: RE: DeltaV doesn't support a true client workspace <cfay> 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. </cfay> <cfay> ... 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. </cfay> <gclemm> 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. </gclemm> I see no value in an Autoversion header on PUT. Clients that are not auto-versioning-aware would not use such a header by definition. If a client is auto-versioning-aware, it doesn't need a special header on PUT to get auto-version behavior only when it explicitly asks for it. It would simply choose to do a single PUT with all its changes, rather than multiple PUTS along the way. <gclemm> 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), </gclemm> I don't follow you here. My proposal is to move the CHECKOUT option back into core versioning, so both CHECKOUT and CHECKIN would be in core versioning. The pre-condition on CHECKIN would still be enforced. That is, CHECKIN would only be allowed on a checked-out resource that was checked out with ... you guessed it ... CHECKOUT. So I don't see the inconsistency you suggest. <gclemm> but also allows you to have just one new header, instead of requiring a new header for every parameter to CHECKIN. So I have two questions: Chuck: Does the Autoversion header for PUT get you what you need? </gclemm> No (see above). To reiterate briefly, I'm trying to avoid a proliferation of versions created by auto-versioning. My server would auto-version only for versioning-unaware clients. Versioning-aware clients would CHECKOUT, GET, do all modifications locally on the client, then CHECKIN with the new content as the CHECKIN request body. What could be simpler? I strongly urge that this model of use be supported by DeltaV. Note that my server would reject any PUTS on a checked-out VCR, because it would not implement my proposed mutable VCR option. <gclemm> 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? </gclemm> Yes, because of the problem of proliferating versions. --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, 9 February 2001 19:31:29 UTC