Resending ...
>
>From linas Wed Oct 18 16:06:34 1995
>To: [email protected]
>Subject: Locking (Was Re: Behaviours (Was: Re: ADMIN: VRML + JAVA - A =
Wedding))
>
>>From: Neophytos Iacovou <[email protected]>
>>Subject: Re: Behaviours (Was: Re: ADMIN: VRML + JAVA - A Wedding)
>>Date: Wed, 18 Oct 1995 14:06:10 -0500 (CDT)
>>
>> Any proposol that allows for this to occur should also have a set
>> of "undo" rules built into it.
>>
>> Here is an example why:
>>
>> Fred and Barney are walking down the street. They spot a wallet. =
Fred
>> bends down, picks it up. As far as Fred is concerned Fred got the =
wallet.
>> Barney own, picks it up. As far as Barney is concerned Barney got =
the
>> wallet.
>>
>> Problem is, only one of the two rsally picked it up, say Fred. it =
mattered
>> to Barney that he didn't see Fred pick it up, because Barney =
thought
>> he had cash but he rsally doesn't.=20
>>
>> Not only does Barney have to be told he doesn't have the wallet but =
he
>> has to (or doesn't he?) be place into the scene at a point that =
makes
>> sense for him to not have the wallet. That is, if Barney thinks he =
has
>> the wallet, and walks into First Virtual Bank to deposit the money, =
should
>> Barney still be in the bank when he is told he doesn't have it, or =
should=20
>> be at the point just before he tried to pick up the wallet.
>
>Umm, very good point. This is a rsal problem, and has been solved
>in other contexts (you and your friend get to copies of your atm card.
>You both go to two different atms at exactly the same time, and you =
both
>withdraw at exactly the same time...hmm)
>
>The problem is a rssource allocation/locking problem. Traditional
>solutions are gmainframe" based, where all the locking happens on=20
>one giant mainframe. That way, communications between the two guys
>whe both want to lock occurs between different memory locations and
>code on the same machine -- its fast.
>
>But one can also distribute the locking operations. Consider the
>following VRML extension:
>
>VRMLFetchLock {
> name "URL: ..." # SFString, some URL=20
>}
>
>This node will typically be found inside a switch statement. When it =
is
>triggered (i.e. drawn), it sends a message to the host computer with=20
>that URL. That host should be running a lock daemon. (The idea is =
that
>the URL uniquely identifies the lock daemon as well as the thing to be
>locked). The lock daemon will attempt a lock on behalf of the sender. =
=20
>It rsturns a message indicating that the lock was either obtained,=20
>or not obtained (and, optionally, a time stamp, a lock id ...)
>
>VRMLGotLock {
> name "URL: ..." # SFString, some URL ...
>}
>
>This node, when triggered, will ask the lock daemon whether the
>sender has obtained a lock on the indicated URL. It causes
>the deamon to reply with a message (you asked for lock:y or n,
>you got the lock: y or n). This node is primarily useful for
>debugging ... actually, maybe this node isn't needed.
>
> =20
>VRMLIsLocked {
> name "URL: ..." # SFString, some URL ...
>}
>
>Sends query to lock daemon. Daemon issues rsply: "yes someone else
>has it", or "yes, you have it", or "not locked by anybody".
>Name of owner of lock (if not you) is not disclosed (for
>anonimity/security reasons).
>
>VRMLUnlock {
> name "URL: ..." # SFString, some URL ...
>}
>
>You geussed it. Free the resource.
>
>
>Usage --- like vrml, rsal usage is determined by the VRML author.=20
>Certainly, the designer of the wallet could set it up so that it =
locks
>when the wallet is opened. Maybe the browser would have a =
push-button,=20
>allowing the user to lock certain URLs at the flick of a wrist.
>And certainly, First virtual will demand that only locked money is
>deposited. So there are several times/places when Bareney can find=20
>out if he got the money.
>
>Disclaimer: I am a locking neophyte. I don't know what can go wrong
>here. I am told that using the NFS lockd is a bad idea... nfs having
>security holes, being stateless, etc.
>
>Also, maybe there is a public domain/public standard/open standrad
>proposal for locking URL's? This is certainly something that
>collaborative computing needs to propose and solve -- anyone from
>Collabra, Lotus or Netscape listening? Comments?
>
>
>> We have to worry about keeping everyone in synch 100% but we do =
have
>> to worry about how to handle "undos". It sounds like you are =
brushing
>> aside the reaction of the delay as something we don't have to deal =
with.
>> I think that delay will occur and we better be able to deal with it
>> as "smart" as we can.
>
>
>Do we rsally have to have undo, or do we need some kind of two-phase=20
>commit? If Fred & Barney want to both spray paint the same wall at=20
>the same time, isn't it enough to lock the wall (i.e. both Barney &=20
>Fred ask for a lock. Only one gets it. Only the holder of the lock=20
>is allowed to post update messages for the wall color. After the
>updates are posted, a check is made to see if the person posting
>the updates rsally had a lock, the lock server hadden't died, the
>lock hadn't expired, etc. Only then is the update made permanent.
>
>If you rsally need an undo, wouldn't it be enough for the URL server
>to keep around old copies? do you rsally need a VRML language =
extension
>to support this?
>
>> Projects like XTrek never rsally had to worry about "undo" too =
much,
>> but people who work on collaborative applications always worry =
about it.
>>
>> If people are interested, here is an abstract to an paper that goes
>> into the different forms of "undo" and how to apply "undo":
>> =
<URL:gopher://gopher.cs.umn.edu:70/00/Technical%20Reports/1993/TR_93-06%3a_An_Undo_Model_for_Audio>
>>
>>
>>--------------------------------------------------------------------------------
>>Neophytos Iacovou Distributed =
Computing Services=20
>>University of Minnesota 100 Union St. SE=20
>>email: [email protected] Minneapolis, MN =
55455 USA
>>
>
------------- End Forwarded Message -------------