RE: Requirements Open Issues from Orem

What is the advantage to be gained from distinguishing between a single resource (whos arbritrator does not have to be "located") and multiple resources (whos arbritrator[s] has to be located first)?

Cheers
Dylan

----------
From: 	Yaron Goland[SMTP:yarong@microsoft.com]
Sent: 	Montag, 4. August 1997 20:04
To: 	'Dylan Barrell'; 'Whelan, Dan'; w3c-dist-auth@w3.org
Subject: 	RE: Requirements Open Issues from Orem

There is an arbitrator for single resources, the resource itself, it is
kind enough to lock itself on your behalf. 

A server could configure itself such that every resource can serve as a
lock arbitrator for all resources on that server.

	Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@bb.opentext.com]
> Sent:	Monday, August 04, 1997 12:52 AM
> To:	'Whelan, Dan'; w3c-dist-auth@w3.org; Yaron Goland
> Subject:	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 Tuesday, 5 August 1997 04:33:40 UTC