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: Thu, 18 Jan 2001 13:04:36 -0500 (EST)
Message-Id: <200101181804.NAA23240@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: "Fay, Chuck" <CFay@filenet.com>

   There seems to be an underlying assumption in DeltaV, even for parts of core
   versioning, that the server provides persistent storage of work-in-progress
   on resources between checkout and checkin.

I don't believe that is the case.  As you point out below, core
versioning allows a server to only support the DAV:when-unlocked
mechanism, which creates a new version on every update.

   This is explicit in the optional
   VCR CHECKOUT-CHECKIN semantics, and in the Working Resource option.

Many of the options are not supported by certain classes of servers,
but that doesn't mean those classes of servers violate underlying
assumptions of DeltaV.

   It is
   also implicit in core versioning when DAV:auto-version is set to
   DAV:when-locked:  between the LOCK and UNLOCK, the server is expected to
   provide persistent working storage for intermediate updates via PUTs and
   PROPPATCHes from the client.

Yes, but the protocol explicitly states that a client should be aware
that a server may not allow change to the DAV:auto-version values, which
means that a server that only supports DAV:when-unlocked is fully
compliant, and should interoperate with core versioning clients.

   Unfortunately, this assumption is not valid for some existing versioning
   systems, including a FileNET content management product and one of the
   software configuration management products we use internally.  These two
   versioning systems employ the concept of what I would call a *real* client
   workspace, where *all* intermediate work-in-progress is stored on the client
   side between checkout and checkin.  A user may choose to store
   work-in-progress on a file server for backup or access from other clients,
   but in any case the versioning server software does not provide any
   persistent work-in-progress storage.

That's OK.  Although the protocol defines how a client interoperates
with a server that provides storage for intermediate work-in-progress,
a variety of the options (e.g. baselines and activities) should work
just fine for a server that does not support intermediate work-in-progress.

   So DeltaV is not a great fit for these two existing systems.  (I won't argue
   that their reliance on a client workspace is necessarily a better design
   than DeltaV's server workspace.  Rather, I raise it as existing practice
   that needs to be considered by DeltaV.)

I agree.

   One alternative is to build a core versioning layer for these two systems
   which would disallow the DAV:when-locked flavor of DAV:auto-version.

That is already legal in the current core versioning definition.

   this would result in a new version for every PUT or PROPPATCH of dead
   properties done by the client.  Arbitrary DeltaV clients are not likely to
   limit themselves to one PUT between a LOCK and UNLOCK, so there would likely
   be a proliferation of unwanted intermediate versions.  Scratch that

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

   Another alternative would be to build a work-in-progress persistence layer
   on top of these existing systems to accommodate DeltaV, but that is a costly
   and awkward choice.

That's your only choice if you want your server to interoperate with
clients that assume functionality that your server does not currently

   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.

The only way that would help you is if we *required* this to be the
only way a client could interoperate with a versioning server.  That
would make the versioning protocol useless for a client that does
not have local persistent storage, so I find it very unlikely that
many would find this acceptable.

   Are there other alternative solutions to this problem?

If the problem is "how to make a client interoperate with a server
that does not provide the functionality required by that client",
then I don't think there are *any* solutions to this problem.

   Do others on the mailing list know of existing versioning systems with this
   same problem with DeltaV?  Or is this problem limited to just these two

Any server that only provides a subset of the defined functionality
will only support the subset of clients that only use that subset.
This is a problem for any server, but it is a logically unavoidable one.

Received on Thursday, 18 January 2001 13:05:49 UTC

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