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 Wednesday, 11 February 1998 17:26:30 UTC