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

FW: DeltaV doesn't support a true client workspace

From: Fay, Chuck <CFay@filenet.com>
Date: Fri, 9 Feb 2001 16:26:32 -0800
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F05E1B8E6@hq-expo2.filenet.com>
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.


-----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

       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.

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.

  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),

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

  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?

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.

  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?

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

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