- From: Sanford L. Barr <sbarr@interwoven.com>
- Date: Thu, 12 Feb 1998 15:04:23 -0800
- To: "'Yaron Goland'" <yarong@microsoft.com>
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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