W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: FW: DeltaV doesn't support a true client workspace

From: Greg Stein <gstein@lyra.org>
Date: Fri, 9 Feb 2001 18:30:39 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010209183039.U26044@lyra.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
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

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.


Greg Stein, http://www.lyra.org/
Received on Friday, 9 February 2001 21:28:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC