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:01:05 UTC