RE: Requirements Open Issues from Orem

It is not a matter of advantage, it is a matter of HTTP's design. HTTP
can only deliver a single message to a single destination. It does not
have multicast or broadcast capabilities. As such without transactioning
the only way to deliver a message to multiple resources in an atomic
fashion is to have the message delivered through some mechanism other
than HTTP. What the arbitrator does is act as the resource which can
access that out of band mechanism.

In the case of trying to atomically lock a single resource one can skip
the out of band mechanism since HTTP does support sending a single
message to a single recipient.

			Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@bb.opentext.com]
> Sent:	Tuesday, August 05, 1997 1:30 AM
> To:	'Whelan, Dan'; 'Dylan Barrell'; w3c-dist-auth@w3.org; Yaron
> Goland
> Subject:	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 15:02:30 UTC