RE: 5.5 Write Locks and COPY/MOVE

Comments below

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Friday, February 13, 1998 12:45 AM
To:	'Dylan Barrell'; 'WebDAV'
Subject:	RE: 5.5 Write Locks and COPY/MOVE

A) 2 in no way contradicts 4 because the server may decide to perform the
MOVE by acting as a DAV client. That is, user Joe told Server A to move a
locked file to Server B and maintain the lock. Server A has no special
ability to communicate with Server B. So what Server A does is act as a DAV
client and send a lock request to server B for the destination. Once locked
Server A then PUTs the contents, PROPPATCHs the properties, and deletes the
original. The move is now done.  Thus the server can move the file and still
have it be locked but not be able to keep the original lock token. Requiring
the original lock to be maintained will make the previous scenario
impossible and thus prevent two non-related servers from being able to
communicate using DAV.
[Dylan Barrell]  Which is exactly why it contradicts saying that the lock may not be able to be preserved.

B) I take issue with the base assumption of your statement that an
administrator can move a file while a user is working on it and not have the
user's program crash and burn. Ignoring the whole lock issue, if you move a
resource that a user is actively editing with any of the common editing
tools such as Hot Metal, Netscape, Office, or even notepad, the program will
just fail. While it is true that some tools may be powerful enough to handle
having their file moved from under them, lock or no lock, those tools do not
form the majority and given the 80/20 rule of protocol design if we can meet
the needs of 80% of the market, which we clearly do on both the client and
server side, then we have succeeded.
[Dylan Barrell]  These are old-style file-system based editing tools. File systems are not a good collaborative authoring infrastructure. WebDAV is supposed to provide this infrastructure. Surely we can do better than this 20 year old metaphor?

If you remove the locking issue (for example a WebDAV server which does not support locking), then you have no way of stopping anybody who has sufficient permissions (eg the administrator) from doing anything with the files that you are editing, so the authoring clients are going to have to be able to deal with this problem anyway. 

	My recommendation to you Dylan is that you write up an extension
spec which provides for the functionality you desire. All client side
editing tools which can handle the functionality you desire will implement
your extension. In the meantime base level tools, which can not handle
having their files moved from under them, will still be able to work against
your store. Hence everyone gets what they want.
[Dylan Barrell]  Having another spec which contradicts the base spec is counterproductive. I would much prefer a base spec which is more useful from the start.

			Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Thursday, February 12, 1998 8:15 AM
> To:	Yaron Goland; 'WebDAV'
> Subject:	RE: 5.5 Write Locks and COPY/MOVE
> 
> I have serious reservations about the usability of a server which requires
> locks to be removed when moving a collection.
> 
> I summarise your arguments as follows
> 
> 1) We do not want anything optional in the spec.
> 2) In moving resources across server boundaries it might be impossible to
> preserve the lock
> 3) Both solutions require the same effort
> 4) The destination could be locked before the move
> 
> I accept the restriction that we do not many optional functionality in the
> spec. This restriction should not however force us to design a spec which
> will result in an unusable system. In large organisations with large
> Intra- and Internet sites, not allowing the web administrators to
> re-organise the structure of the web site without adversely affecting the
> work being done by the authors of the individual pages is unacceptable.
> 
> I would prefer to require that resource be copied across server boundaries
> than restrict the power of the MOVE command. It is intuitive for COPY not
> to replicate any locks. Also as you said the server could always lock the
> destination before copying the resource thereby achieving the same effect
> (argument 4 negates argument 2). It is not practical for the client to do
> this for various reasons 
> 	1) The principle might not own all the locks involved which would
> result in the target locks belonging to the wrong person.
> 	2) The client would have to perform lockdiscovery for all resources
> involved and perfomr the individual lock methods to lock the destination
> 	3) The client might not be aware that the namespace is on another
> server.
> 
> The argument that both solutions require the same effort is not valid. I
> can think of many ways of implementing collections whereby a move of an
> entire subtree could be performed by updating only one database
> row/directory table and many more which would require only two updates.
> 
> Cheers
> Dylan
> 
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Wednesday, February 11, 1998 11:26 PM
> To:	'Dylan Barrell'; 'WebDAV'
> Subject:	RE: 5.5 Write Locks and COPY/MOVE
> 
> If the functionality is optional than it need not be in the specification,
> it can always be placed in a separate specification. One would indicate
> support for the optional feature through the OPTIONS method and then use a
> header declaring that the optional feature is to be used on a particular
> command.
> 
> One of the decisions made early on in the DAV working group is that there
> are two kinds of features, mandatory and not in the spec. The reason for
> that decision is that we realized that the combinatorial complexity of
> optional features in such a large spec would make it impossible to have
> interoperable implementations. The chance of a random client and server
> being able to communicate would fall rapidly to zero. That is why the spec
> only has two compliance settings, the second of which requires all of the
> first.
> 
> The result is that the spec has roughly 158 MUSTs, 22 SHOULDs, and no
> MAYs.
> Of those roughly 102 MUSTs belong to level 1, 14 SHOULDs belong to level
> 1,
> 39 MUSTs belong to level 2, and 5 SHOULDs belong to level 2.
> 
> 			Yaron
> 
> P.S. The reasons the numbers don't add up is that I am using a compliance
> spreadsheet which combines some of the requirements on the same line. So a
> single entry in the spreadsheet may have two or three MUSTs listed because
> they appear in the same sentence.
> 
> > -----Original Message-----
> > From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> > Sent:	Wednesday, February 11, 1998 8:23 AM
> > To:	Yaron Goland; 'WebDAV'
> > Subject:	RE: 5.5 Write Locks and COPY/MOVE
> > 
> > Why not make the requirement optional thereby allowing servers which can
> > deal with the complexity described to do so.
> > 
> > Cheers
> > Dylan
> > 
> > -----Original Message-----
> > From:	Yaron Goland [SMTP:yarong@microsoft.com]
> > Sent:	Tuesday, February 10, 1998 11:48 PM
> > To:	'Dylan Barrell'; 'WebDAV'
> > Subject:	RE: 5.5 Write Locks and COPY/MOVE
> > 
> > The main issue in moving a locked resource is ensuring that the
> > destination
> > is able to keep the lock. Most file system implementations can not move
> a
> > locked resource at all and many web servers have namespaces which look
> > consistent but in fact are implemented across multiple servers. So, for
> > example, you may go to a web server and see the collections a/b and a/c.
> > However both collections, while in the same namespace are in fact on
> > different volumes or even on different servers and as such the web
> servers
> > do not have the ability to maintain the lock in a move between these
> > namespaces. As such requiring that moved resources retain their locks
> was
> > considered unacceptably onerous.
> > 
> > As for efficiency, either solution causes the same cost. If we require
> > that
> > moved resources loose their locks then some systems will have to check
> all
> > files in a deep move to see if any are locked. If, on the other hand, we
> > require that the lock be kept than the majority of implementations will
> > have
> > to do the exact same search in order to determine if they should fail
> the
> > move because a resource is locked. However both arguments are not
> terribly
> > germane as moving or copying a hierarchy requires that one transverse
> the
> > entire hierarchy, it is the very nature of the operation.
> > 
> > Furthermore the functionality your seek, being able to move a file while
> > keeping it locked, already exists. One can lock the destination, either
> at
> > depth 0 for a single resource or depth infinity for a collection, and
> then
> > move the file. The additional benefit of this mechanism is that it will
> > work
> > even between two servers or volumes which may not be able to exchange
> lock
> > information. Please note that the user need not be aware that a second
> > lock
> > is being taken out. The UI can simply show that the file has been moved
> > and
> > is still locked, the fact that the lock token has changed should be of
> no
> > concern to the user.
> > 
> > It is true, however, that there is a fault here. If one were to lock a
> > collection and then move a single resource then the lock under which the
> > single resource now resides would not include the members of the
> > collection.
> > Thus guarantees made by a single lock across multiple members would be
> > lost.
> > However providing the functionality to allow for the movement of some
> > members of a lock while maintaining the other members of the lock has
> > previously been included in the specification but was removed, by group
> > consensus, because it was felt that the feature was so complex that
> there
> > was no hope that most systems could implement it.
> > 
> > As such the basic ability to move a file and keep it locked is
> available,
> > the argument of efficiency does not hold up as the same cost will be
> paid
> > regardless of which solution is chosen, and an extension mechanism
> exists
> > to
> > allow for these more complicated and expensive locks to be implemented.
> > 
> > It would then appear, in my humble opinion, that the requirement may
> stay.
> > 
> > 			Yaron
> > 
> > > -----Original Message-----
> > > From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> > > Sent:	Monday, February 09, 1998 6:47 AM
> > > To:	'WebDAV'
> > > Subject:	5.5 Write Locks and COPY/MOVE
> > > 
> > > section 5.4 states that a write lock must not be moved when a resource
> > is
> > > moved. This is not the way that DMS systems should behave. There are
> > > generally different sets of users respnsible for server structure and
> > > content. The users responsible for the structure may like to move
> > > resources around. Users who are editing these resources will not be
> > happy
> > > if their lock gets revoked.
> > > 
> > > It also causes problems because it allows a user to release a lock on
> a
> > > resource by simply moving a tree structure which contains the resource
> > in
> > > question - whether their permissions allow this. It is therefore an
> > > implicit restriction on the permission model of the WebDAV server.
> > > 
> > > It is furthermore problematic because it requires a server which has
> to
> > > comply with this to scan the tree structure of an entire collection
> > > hierarchy which is being moved and release all locks on all children.
> > This
> > > will make efficient move impossible to implement. If this requirement
> > does
> > > not have-to be met then moving a very deep collection could be done by
> > > simply moving the parent collection entry from the current parent to
> the
> > > future parent.
> > > 
> > > This requirement MUST go.
> > 
>

Received on Monday, 16 February 1998 09:58:40 UTC