Re: DeltaV doesn't support a true client workspace

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.)
<jra>
I think DeltaV will work fine for these systems using auto-versioning. See 
below.
</jra>

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.  But
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
alternative.
<jra>
This solution is already possible. Your client can use auto-versioning 
when synchronizing updates between the client's private workspace, and the 
server (which would represent some shared resource pool). In this case, 
DAV:auto-version is really all you need because your clients only update 
on synchronization, not on every PUT. To prevent proliferation of unwanted 
intermediate versions, use other techniques to control client access 
including turning off auto-versioning, or access control.
</jra>


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.
<jra>
That would couple CHECKIN and PUT and require CHECKIN to have multi-part 
MIME request contents. Sounds tricky, and a compromised design.
</jra>