RE: "Lost Updates" still persist...

Another way of looking at this is that the same server might have areas which are being accessed by multiple users (collaborative) and areas which are the responsibility of a single user. Different access will be required to the two areas. There might also be areas where the users accessing the repository are dispersed geographically and temporaly and other situations where they all sit in the same room and know exactly what each of the other members is up-to (out of band communication). Different types of locks, control mechanisms and processes are required in all of these different environments. In the close-knit community, requiring that they use write locks might be more of a hassle than an advantage.

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Saturday, February 14, 1998 8:25 AM
To:	'Sanford L. Barr'; 'ejw@ics.uci.edu'; 'WEBDAV WG'; 'jdavis@parc.xerox.com'
Subject:	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 Monday, 16 February 1998 15:08:17 UTC