- From: Greg Stein <gstein@lyra.org>
- Date: Fri, 9 Feb 2001 18:30:39 -0800
- To: ietf-dav-versioning@w3.org
On Fri, Feb 09, 2001 at 04:26:32PM -0800, Fay, Chuck wrote: >... > 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. Fine. DeltaV can accomodate that without change. > 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) How about: GET /foo.html Modify content locally, saving intermediate state locally or on a file server. PUT /foo.html That accomplishes exactly the same task as you requested. Why do we need to change the current spec? If your versioning-aware client (a given since you mentioned CHECKIN) can stash content locally, then it can hold all changes until a single PUT occurs. Further, you can have your server set DAV:auto-version to be DAV:always-checkout-always-checkin and not allow clients to change in. That will explicitly tell clients that any change will create a new version. Thus, you can offer a Core server to do exactly what you are requesting. No need for the "CHECKOUT OPTION" or for any change in the Core. > 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. I don't believe anybody has asserted that. If they have, then they're wrong :-) I believe my counter-example above shows that a server can effect this model with the current definition of Core. > 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. And in the current model, if a client cannot buffer changes locally, they they'll do a number of PUTs, which create a number of versions. Your proposed model doesn't change that resulting behavior. > 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. I can easily imagine it, and I hope that I've easily explained it :-) To me, a Core server is defined to do auto-versioning for versioning-unaware clients. For clients that have a bit of versioning awareness, they can do a few nifty things, but the mechanisms for *creating versions* are very limited. Much of the query / discovery facilities are present, however. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Friday, 9 February 2001 21:28:54 UTC