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

Re: DeltaV doesn't support a true client workspace

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 3 Feb 2001 16:55:24 -0500 (EST)
Message-Id: <200102032155.QAA18022@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
   From: "Fay, Chuck" <CFay@filenet.com>

   > ... Well, there is not much you can do about making a client that
   > requires intermediate storage on the server (perhaps because it
   > has none of its own) to interoperate with a server that does not
   > provide intermediate storage.  That's the same for many of the
   > other options (i.e. they are server options because clients want
   > the servers to do that work).

   Sure, clients that depend on features not supported by a particular
   server won't work with that server.  (As an aside, that's the
   danger of having lots of options that won't necessarily be
   supported by all the server implementations.  That's my main
   concern with the baroque set of options currently in DeltaV.)

The alternative is either having no way for clients and servers that
require that functionality to interoperate, or requiring that your
server support something that you clearly don't want to support.  If
we are forced to chose between "requiring intermediate server state"
and "disallowing intermediate server state", I can confidently predict
that the consensus will be "requiring server state".  If so, your
server will have no way of advertising that it has any versioning

Every other "baroque" option has exactly this characteristic ... there are
a significant number of implementors that are depending on that option
to achieve interoperability, but there are also several implementors
that insist that they will not support that option, but do want to
advertise that they support some other versioning capabilities.

   >    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

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.

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),
but also allows you to have just one new header, instead of requiring
a new header for every parameter to CHECKIN.

   Besides the change to CHECKIN, clients will need a means to determine if the
   server supports storage of intermediate state.  I propose creating a new
   option called "Mutable Checked-out Version-Controlled Resource Option" to
   replace the current CHECKOUT option.

Well, that is a really catchy name (:-), but if we just add an
Autoversion header for PUT, we can leave it as the "checkout option".

So I have two questions:

Chuck: Does the Autoversion header for PUT get you what you need?
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?

Everyone else: Do you think that the Autoversion header for PUT is
of sufficient value to be worth putting into core?  It is a way
for a versioning client to interact with a server like Chuck's
without forcing his server to have every PUT to a version-controlled
resource result in a new version.

Received on Saturday, 3 February 2001 16:56:22 UTC

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