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

I agree with Greg's response below.

Also, if you want to make sure that only a versioning-aware
client creates new versions (e.g. to make sure that a
auto-saving versioning unaware client doesn't create a
flood of versions), make your DAV:auto-version property
modifiable by your client (only allowing the value to be
empty or DAV:always-checkout-always-checkin), and then initialize
DAV:auto-version to be empty.  An attempt by a versioning
unaware client to update the resource will fail, but a
versioning-aware client can LOCK the resource, set the
DAV:auto-version property to be DAV:always-checkout-always-checkin,
do the PUT, set the DAV:auto-version property back to empty,
and then UNLOCK the resource.

So like Greg, I don't see that the protocol needs to be
extended for you to do what you want.

Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Friday, February 09, 2001 9:31 PM
To: ietf-dav-versioning@w3.org
Subject: Re: FW: DeltaV doesn't support a true client workspace


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 Saturday, 10 February 2001 00:03:41 UTC