RE: Proposal: BIND method

>> If we have UNBIND, we need to specify its interaction with LOCK.
>> Presumably we at least want to prevent an UNBIND on the URL that
>> was used to create the LOCK, but it might be easier (since
>> it's the resource that's locked) to prevent any UNBINDs to a
>> resource while the resource is locked.
>
>Hmm.  This boils down to the question of the relationship between bindings
>and a resource.

Radical proposal: the binding is truly a separate name for the same resource, and there is no discernable distinction between the two different names (just like a Unix hardlink).  Then the sequence "BIND A to B, UNBIND A" (or the other way around) would be equivalent to a MOVE.  In this case, it is clear that a LOCK on one name must lock all names, since they're all the same resource.


--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal, Inc.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

--

Received on Wednesday, 7 April 1999 22:34:13 UTC