Re: Requirements Open Issues from Orem

>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.
>

A good server implementation of a mulitple lock request would be to
release all locks previously obtained in the lock request when one of
the requests time out. This would prevent the problem noted.

>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." 

I still concur with the statement above. Any collating should be done by the
DMS concerned with the request anyway.

>
>"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."

I concur with this.

-src
Steve Carter
CTO, Novell Applications Division
1555 North Technology Way MS Orem F111
Orem, UT  84097-2399

801-228-5175
801-228-5176 fax
srcarter@novell.com
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                        

Received on Tuesday, 22 July 1997 17:46:22 UTC