RE: "Lost Updates" still persist

If a client chooses to not use locking mechanisms available on the server
then they might suffer from the lost update problem. That is their choice.
Clients can always do the wrong thing, the onus is on the protocol is to
make sure it is easy for them to do the right thing.

Furthermore A could avoid the lost update problem all together without ever
having to take out a lock by using the HTTP e-tag mechanism which all
HTTP/1.1 compliant servers MUST support. When client A performed the get it
should have received an e-tag. When Client A then performs its put it can
always submit the e-tag in an if-match header. This says to the server "If
the get response is not in the same state as identified by this e-tag then
you must fail this request."

			Yaron


> -----Original Message-----
> From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> Sent:	Thursday, February 12, 1998 3:04 PM
> To:	Yaron Goland
> Cc:	'w3c-dist-auth@w3.org'
> Subject:	RE: "Lost Updates" still persist
> 
> 
> Yaron, thanks for taking the time to go over some of the issues with me. 
>  I'd like to go over a few of the other issues with you again, but for now
> 
> I'd like to focus on the point about optional client locking which sits 
> unresolved, here's the specifics:
> 
> > Lock Ordering - There is no lock ordering requirement, that is
> completely
> > under the control of the client. If you want to make sure you don't have
> > lost update issues make sure you lock before you do the GET.
> 
> Between this comment and the spec I'm reading "Clients may or may not 
> choose to participate in locking".
> 
> 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.
> 
> Here's the scenario from the previous letter in more detail - Here's a 
> specific example where this fails:
> 
> Two clients A and B are interested in editing the file 'index.html'.
> 
> Client A doesn't choose to lock the document, does a GET and begins 
> editing.
> Client B does LOCK, does a GET and begins editing
> Client B finishes editing, does  PUT then an UNLOCK
> Client A does a PUT overwriting and _loosing_ all of B's changes.
> 
> As you can see, if a WEBDAV server supports locking, unless all clients 
> adhere to the locking model.  There is no freedom to allow some clients to
> 
> simply GET/PUT without locking and still have a valid locking scheme.
> 
> Again, my apologies if I've missed something obvious in the spec, but if
> it 
> hasn't been addressed, there does seem to be a hole in the current locking
> 
> design.
> 
> My suggestion is that the spec explicity require clients to determine if 
> locking is in use, and if so, the clients must participate by taking locks
> 
> on the requested documents.
> 
> -San
> 
> 
> 
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Wednesday, February 11, 1998 10:40 PM
> To:	'Sanford L. Barr'; 'w3c-dist-auth@w3.org'
> Subject:	RE: Spec clarifications
> 
> Sanford, your points are dead on and identify the areas where WebDAV is
> working. However I think the core of your concern is the perception that
> somehow the current Distributed Authoring spec is the end of the process.
> The DA spec is only the first step in a series of specification. It 
> provides
> the most absolute basic functions which will then be leveraged by the
> other
> specs. So, for example, the next two specs that this working group has
> committed to delivering are Access Control Lists and Versioning. In 
> addition
> a new working group on Search is being formed which is also leveraging the
> DAV specs as its foundation.
> 
> Staged Systems - Staged systems are very common, even before the web.
> However you will notice that the DA spec works perfectly well as a
> communication mechanism between the editing software and the first stage.
> What is missing is the ability to say "roll this out." The reason that
> functionality is not in the spec is that so many systems implement this
> function in so many incompatible ways that the working group came to the
> decision that it wasn't practical to standardize this functionality. You 
> can
> only standardize something that is very well understood and is done in
> essentially the same way by everyone. Standards are not the way to get
> everyone to agree to do the same thing. Standards are what you use to
> formalize matters once everyone is doing the same thing, the same way.
> However the beauty of the DAV specs is that they are like Lego blocks. So
> you can easily take the DA spec and the V spec and the ACL spec and put 
> them
> together with a submit command spec. Old DA only compliant systems will
> still work and will only need a little extra software to be able to give 
> the
> submit command.
> 
> Locking - See section 4.2. But in what I suspect may be a more useful 
> answer
> to your question, systems which choose not to supporting write locks will
> suffer from the lost update problem. That is their choice. Although many
> systems which do not use locks or use shared write locks instead depend 
> upon
> advanced merging facilities. The Versioning spec will be addressing the
> issue of how to handle merging.
> 
> Lock Ordering - There is no lock ordering requirement, that is completely
> under the control of the client. If you want to make sure you don't have
> lost update issues make sure you lock before you do the GET.
> 
> Discovering the Source - I'm not sure what more I can say that isn't 
> already
> said in section 12.11.
> 
> What can be stored in properties - Section 2.4: "The value of a property
> is
> expressed as a well-formed XML document." I'm not sure what more can be
> said.  As for size limits, that is implementation specific.
> 
> Reservations - Versioning, including reservations and such, will be dealt
> with in its own specification.
> 
> 		Yaron
> 
> 
> > -----Original Message-----
> > From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> > Sent:	Wednesday, February 11, 1998 7:22 PM
> > To:	'w3c-dist-auth@w3.org'
> > Cc:	'sbarr@interwoven.com'
> > Subject:	Spec clarifications
> >
> >
> > After reviewing the current -06 draft and mentally mapping the protocol
> > onto existing web collaboration systems, I have the following questions.
> >  Since I'm new to the spec, I apologize if I'm rehashing items that have
> > already been discussed and clarified:
> >
> > As I read the spec it seems that the current WEBDAV protocol is very
> > single
> > site, live content centric (content is taken directly from a live site,
> > edited and returned directly to the live site).  In all but the simplest
> > organizations this usually isn't the case.  Most corporations that I'm
> > familliar with have development servers (staging servers, with 
> individuals
> >
> > having separate workareas) from which content is then moved to QA
> [legal, 
> > etc.] and then eventually through to a production server.  It doesnt
> seem 
> > clear from the current spec how these common authoring environments are
> > addressed by the current WEBDAV draft.  The best I can guess is that a
> > 'PUT' and the associated 'UNLOCK' could be overloaded to imply an 'OK 
> move
> >
> > the content to the next stage' but a more explicit 'SUBMIT' (an explicit
> > command signifying the completion of a specified unit of work which
> would 
> > trigger additional workflow) on a collection of associated items seems
> > more
> > in order.
> >
> > Has the working group already discussed an approach to this scenario 
> using
> >
> > the current set of defined methods?
> >
> > There are also some specifics that seem unclear at first reading:
> >
> > *) Client requirements for locking support
> >
> > There doesn't seem to be any client requirements for forcing locks to be
> > used if they're supported by the WEBDAV server.  If locking support (if 
> it
> >
> > exists on the WEBDAV server) is not strictly required of the clients,
> the 
> > "Lost Update" problem will still persist (A does a GET, B does a LOCK,
> > GET,
> > edit then PUT, UNLOCK, A then does a PUT overwriting B's changes).
> >
> > *) Client lock ordering.  The spec doesn't seem to make mention of the
> > order of operations when locks are involved.  Specifically, If a client
> > chooses to edit, and locking is supported, the file must be locked
> before 
> > the edit can begin, otherwise conflicts can occur.  Currently it seems
> ok 
> > for a client to do a 'GET' and then later try to acquire the lock on the
> > item in question (opening up the possibility for the "Lost Update"
> > scenario
> > above).  Actually as I reread page 14 it does loosely imply the
> > lock/get/put/unlock ordering, but this could be more explicit.
> >
> > *) How to discover "real" source of a file (seems vague from spec)
> >
> > As noted in the spec, one of the more common operations is how to 
> discover
> >
> > the real source(s) of a rendered file (i.e. a file with server side
> > includes).  The current draft refers to inline 'links', but seems vague.
> >  Was there any consideration of using live properties or another more
> > defined method to address this?
> >
> > *) What can be stored in properties (arbitrary unicode for dead and live
> > values?), any size limits, etc?
> >
> > *) No provision for submission 'Reservations'
> >
> > The spec only addresses explicit write lock, discusses shared lock but
> > punts on recommondations.  Many site management systems have a concept
> of
> > a
> > 'Reservation' (guarantee to submit without conflict, while others may
> > still
> > be allowed to merge).  While it seems that the current spec has
> > sidestepped
> > version control - not being able to coexist with existing systems and
> > detect conflicts seems to be a significant drawback.  Overall the
> > exclusion
> > of versioning in this draft renders the spec almost unusable except for
> > extremely small scale sites (a handful of non conflicting contributors).
> >
> >
> > In closing, I'm hoping that the working group will take a careful
> > consideration of the issues involved with WEBDAV integrating with 
> existing
> >
> > versioning and workflow systems before ratifying the current draft
> > specification.  I'd personally like to see the industry adopt WEBDAV,
> but 
> > in it's current form, the omission of versioning and the lack of
> enabling 
> > even the most simple workflow trigger (collection submit) seems to limit
> > its overall usefulness, and makes it difficult to integrate effectively
> > into existing site management, versioning and workflow systems.  I 
> believe
> >
> > with a little extra refinement and discussion the current spec could be
> > extended to address these needs.
> >
> > --
> > Sanford L. Barr
> > Manager, Internet Technology Group
> > Interwoven, Inc. 885 N. San Antonio Rd., Los Altos, CA 94022
> 650/917-3600 
> > ext 219

Received on Thursday, 12 February 1998 18:16:33 UTC