RE: "Lost Updates" still persist...

Jim,

I'm here as a representitive of Interwoven, and our business is web collaborative
authoring systems.  First, please let me share my thanks for all of the
hard work the WEBDAV working group has gone through so far, I realize
that many of you have been hard at work for almost two years trying to
create a generic method to tackle a very hard problem.  A standard
communication protocol between authoring clients and content
repositories would be a tremendous boon to the industry as a whole,
and I'd like to see WEBDAV's efforts successfully and rapidly adopted by client
and repository vendors.

As I understand it, the original intent of the working group was to cover the wide
scope of Versioning, Merging and content management.  As I see it, it seems the
current approach is to focus more narrowly on a few basics and develop later
RFC's to build on a solid foundation.

The reason I'm here voicing my concerns is that our team finds (and I'm sure the teams
of a few other repository vendors would agree) the current base specification
inoperable with any of the existing systems that we're aware of.

The key issue is:

a) A specified but non enforced strict locking model, which doesn't prevent changes
    from inadvertantly getting lost.

In addition the lack of the following will make WEBDAV clients bad citizens
by forcing long term locking on concurrent versioning style systems (ala GNU's CVS, etc.)

b) A loosely specified and generally non-standard 'shared' mode
c) The lack of any specification for conflict detection, resolution or merging
   (The lack of version histories being addressed only makes this task more difficult)

The bare minimum to make WEBDAV support true distributed authoring
is to get the basic locking mechanism correct.  If there isn't an enforced
locking model adhered to by all clients, the protocol is functionally equivalent
to not using locks at all.  Since we're all well versed in the field of computer
science, I'm sure this strikes a chord (just imagine the chaotic mess your
email inbox would be if the mail clients weren't forced to adhere to a locking
protocol).

So, let's focus on getting one thing right.  If we can get an enforcable locking model
fully specified, this would create the bare minimum needed to address the bigger
issues of Versioning, Merging, Reservations, etc.  If we can also think ahead to
the requirements needed by concurrent systems and avoid crippling them in
this spec, then we run the chance of getting even wider industry acceptance.

Implementation: 

Back to specifics, Jim, I hear your concerns about keeping backwards compatibility,
but maybe we can address those in a different manner.  The key issue you mention
is making sure we don't break 'PUT' compatability with downrev clients/browsers.
The drawback with allowing random PUT's is that this breaks any possible locking
guarantee's the system can give.  Here are two approaches to a solution:

1) Let's not modify the behavior of HTTP1.1's PUT, but instead create a 'DAVPUT' or
'PUTL'  that requires a valid lock token.  This gives us the ability to define what
a WEBDAV compliant client is separate from HTTP1.1 compliance.  With locking
enabled the WEBDAV server would disable 'PUT', or restrict it to resources that
aren't being locked.

2) An alternate approach is that a lock enabled WEBDAV server will disable
'PUT' unless a valid lock had been taken out by the same author/client.

Either approach gives some strength to the phrase 'WEBDAV' compliant, and additionally
give's the WEBDAV server a method to refuse downrev browser's from participating
if strict locking is enabled, which is really our goal. 

Avoiding Conflicts and why Etag's aren't enough:

The only way to avoid conflicts is to have every WEBDAV client forced to participate
in at least the exclusive locking model for edits.  The 'etag' solution that was previously
posted will detect a conflict, but leaves clients to have to deal with merging, which is
out of the scope of this current spec and as I agree with both you and Yaron, should
be avoided until we can address it in a more complete manner.

-San

--
Sanford L. Barr
Engineering Manager, Internet Technology Group
Interwoven, Inc. 885 N. San Antonio Rd., Los Altos, CA 94022 650/917-3600 ext 219



-----Original Message-----
From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
Sent:	Friday, February 13, 1998 3:00 PM
To:	'WEBDAV WG'
Subject:	RE: "Lost Updates" still persist

Sanford,

On Thursday, February 12, 1998 3:04 PM, Sanford L. Barr 
[SMTP:sbarr@interwoven.com] wrote:
>
> I claim if you don't enforce locking to be adhered to by all clients, 
then
> "Lost Updates" for those clients who _do_ lock are still possible.
>

I think we are all in agreement that the scenario you outline is possible 
given the way locking is defined in the current specification. What we 
differ over is the perception of how significant this is.

To start with, let me point out that the same scenario you outline is also 
possible using shared locks.  The resolution to overwrite conflicts using 
shared locking is to employ some form of floor control which is negotiated 
out-of-band of the WebDAV protocol, for example, talking on the phone to 
see who can make changes next.  While your scenario differs from shared 
locks in that there is no way to discover that someone else is editing 
(i.e., in your scenario, lock discovery isn't possible), I suspect the 
resolution to overwrite conflicts will be the same: use of out-of-band 
floor control negotiation among collaborators.

Technical solutions to this problem are not obvious.  If you require a lock 
token to be submitted for PUT, this is difficult to enforce against 
downlevel HTTP servers which will ignore the Lock-Token header for PUT, 
seemingly behaving correctly (because they ignore headers they don't 
understand), but really not.  If you insist that clients working against a 
DAV server use locking, how should downlevel HTTP/1.1 clients which support 
PUT be handled?  After all, they are using PUT the way it is specified in 
the HTTP/1.1 spec.

Yaron's solution of requiring all clients which use PUT to submit the 
entity tag of the pre-edit resource with an If-Match header when submitting 
a PUT request would address the problem, but would not help downlevel 
PUT-capable clients which do not support this capability.

Another approach is to provide a "write-only-if-locked" access control 
type, which would make the resource writeable only if it is locked.  This 
would exclude downlevel PUT-capable clients, without having to mandate a 
use order between methods, a dubious proposition for a stateless protocol 
like HTTP.

- Jim

Received on Saturday, 14 February 1998 00:54:14 UTC