RE: Requirements Open Issues from Orem

Having an arbitrator for locking multiple resources and the server for locking single resources is very contrived and doesn't make sense. The locking part of the standard is anyway optional (the single axis of negotiation) so if a server doesn't want to implement it it doesn't have to but if it does then WebDAV should specify a consistent standard method by which this can be implemented. If you want an arbitrator for locking multiple resources then it should be used for locking single resources too.

Cheers
Dylan

----------
From: 	Yaron Goland[SMTP:yarong@microsoft.com]
Sent: 	Mittwoch, 30. Juli 1997 21:03
To: 	'Whelan, Dan'; w3c-dist-auth@w3.org
Subject: 	RE: Requirements Open Issues from Orem

I suspect we will end up with a LOCK implementation where you have the
concept of a LOCK arbitrator who accepts a list of resources to be
locked and then locks them on your behalf in an atomic fashion. Of
course this means discovering who the lock arbitrator is for all the
involved resources, assuming one arbitrator can cover them all.
Alternatively one can discover what arbitrators exist for a particular
server and what namespaces they cover on that server. Either way, I
suspect most folks will simply lock each resource individually.

		Yaron



> -----Original Message-----
> From:	Whelan, Dan [SMTP:dan@filenet.com]
> Sent:	Wednesday, July 23, 1997 10:50 PM
> To:	w3c-dist-auth@w3.org
> Subject:	RE: Requirements Open Issues from Orem
> 
> I view the proposal to use containers to implement multi-resource
> locking as
> a somewhat clumsy way to satisfy this requirement for a number of
> reasons
> including:
> 
> 1. The principal may not be authorized to create a container, or to
> file a
>     resource in a container, and hence could not use this mechanism to
>     perform a multi-resource lock even if he was authorized to lock
> each of
>     the resources.
> 
> 2. Creating a transient container in order to obtain a multi-resource
> lock
>     is relatively inefficient, requiring O(2N) operations.
> 
> 3. Servers may elect to implement only session based locks or short
> lived
>     timer based locks to provide robust services in an otherwise
> unreliable
>     environment.  In such cases, a client is just as likely to fail to
> remove
>     a transient container as he is to unlock a lock yet the server has
> no
>     WebDAV sanctioned way of removing these transient containers.
> 
> I'd prefer to see the LOCK and UNLOCK methods take an ordered list of
> resources
> to LOCK or UNLOCK respectively.  (I'm not familiar enough with HTTP to
> know if
> the protocol makes passing a list of resources difficult -- WebDAV has
> already addressed
> multi-status responses for the COPY, MOVE and DELETE methods)
> 
> 							Dan Whelan
> 							FileNet
> Corporation
> 	----------
> 	From: 	Judith Slein[SMTP:slein@wrc.xerox.com]
> 	Sent: 	Monday, July 21, 1997 12:33 PM
> 	To: 	w3c-dist-auth@w3.org
> 	Subject: 	Requirements Open Issues from Orem
> 
> 	A new version of the requirements draft will be submitted to the
> IETF on
> 	Thursday, 7/24.  Your comments on these issues discussed at Orem
> will be
> 	helpful.
> 
> 	------------
> 
> 	Multiple Resource Locking
> 
> 	As a result of the discussion at Orem, I was asked to raise the
> issue of
> 	atomic locking of multiple resources to the mailing list one
> more time.
> 
> 	In an informal vote by those present for the discussion, 9 voted
> to keep the
> 	requirement, 4 to remove it.  The rest (about 10 others) did not
> vote.
> 
> 	At the moment, the requirement reads as follows:
> 
> 	5.3.1.2. Multi-Resource Locking. It must be possible to take out
> a 
> 	lock on multiple resources residing on the same server in a
> single action,
> 	and this locking operation must be atomic across these
> resources.
> 
> 	("residing on the same server" was added at the request of the
> group at Orem.)
> 
> 	The rationale for the requirement is to prevent livelocks.  That
> is, if the
> 	requirement is not satisfied, it will be possible for 2
> principals to try to
> 	lock the same group of resources, and for neither to get all the
> locks he
> 	needs.  Each may end up with only some of the locks he needs. In
> addition,
> 	the requirement is meant to lessen the burden on the server that
> would be
> 	caused by multiple individual lock requests.
> 
> 	The current locking draft does not satisfy the requirement.  The
> difficulty
> 	is that it defines a LOCK method where the request URI is the
> resource to be
> 	locked.  If we tried to accommodate multiple URIs by moving them
> into the
> 	body of the request, it is not clear what request URI would be
> appropriate.
> 
> 	One suggestion was that the user put all the resources to be
> locked into a
> 	container, and then lock the container.  The server would be
> required to
> 	treat the lock request as atomic to whatever depth was
> requested.
> 
> 	------------
> 
> 	The requirement concerning EMail transport will stay as is.
> 
> 	------------
> 
> 	Internationalization
> 
> 	The consensus of the group at Orem was that we should stay away
> from issues
> 	around variants, which are not specific to internationalization
> and would
> 	add enormously to the work of WEBDAV.  Jim will make sure that
> this position
> 	is acceptable to the area directors.
> 
> 	The question was raised whether we need to be concerned about
> collation.  We
> 	think that we do not -- we do not sort any query result sets,
> and we do not
> 	define greater-than or less-than operators for pattern matching.
> 
> 	We think that we need only to insure that any information
> intended for user
> 	comprehension should be expressed in a way that makes it
> possible to display
> 	the information in any desired writing system and language.  The
> proposed
> 	internationalization requirement is the following:
> 
> 	"All information intended for user comprehension must be
> expressed in one of
> 	the ISO-10646 character sets and must have a language tag." 
> 
> 	------------
> 
> 	Reservations
> 
> 	The consensus of the group at Orem was to leave the reservations
> section
> 	separate, as it is now, and to continue to use the same
> terminology.  The
> 	locking draft will discuss the standard use of the word
> "reservation" and
> 	explain how the shared lock satisfies the need for reservations.
> 
> 	The language of 5.4.1.1 will change to make it clear that the
> point of
> 	reservations is to inform other users, not the server, of an
> intent to edit.
> 	The new 5.4.1.1 will say:
> 
> 	"It must be possible for a principal to register with the server
> an intent
> 	to edit a given resource, so that other principals can discover
> who intends
> 	to edit the resource."
> 
> 	-----------
> 
> 	--Judy
> 
> 	Name:		Judith A. Slein
> 	E-Mail:		slein@wrc.xerox.com
> 	Phone:  	(716) 422-5169
> 	Fax:		(716) 265-7133
> 
> 	Xerox Corporation
> 	Mail Stop 105-50C
> 	800 Phillips Road
> 	Webster, NY 14580
> 
>

Received on Monday, 4 August 1997 04:03:52 UTC