RE: "Lost Updates" still persist...

If someone writes a buggy client that is so unbelievably stupid that it
assumes that resources do not change over time then might I respectfully
suggest that the market will very quickly make the product a failure. 

This is not an issue of a protocol requirement, this is an issue of common
sense. 

Alas, one can not require common sense.

		Yaron

> -----Original Message-----
> From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> Sent:	Friday, February 13, 1998 9:52 PM
> To:	'ejw@ics.uci.edu'; 'WEBDAV WG'; Yaron Goland;
> 'jdavis@parc.xerox.com'
> Subject:	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 02:25:43 UTC