> From: Neophytos Iacovou <[email protected]>
> Subject: Re: Locking (Was Re: Behaviours (Was: Re: ADMIN: VRML + JAVA =
- A Wedding))
> Date: Thu, 19 Oct 1995 13:52:22 -0500 (CDT)
>
> Linas Vepstas writes:
> >=20
> > >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 =3D
> > both
> > >withdraw at exactly the same time...hmm)
>=20
> But in the message I responded to you were implying that you =
would
> like to see things occur "instantaneously" and you latter (next =
point)
> said that a small delay didn't matter between the time you did
> something, and when your friend saw you do something.
I did not mean to suggest that everything needs to be locked. =20
Yes, locking requires a round-trip, slows performance, the whole
bit. I was merely trying to suggest that the author of a scene=20
should be given the controls to allow the author to determine whether
things need to be synchronous, or can run asynchronously; etc.
Part of these tools might include a way of controlling who/how/when
where chagnes can occur. Presumably, an author would choose to place
locks around important events, such as removing money from a wallet.
The author may not want to synchronize/lock updates for the
windmill example or the falling vase example. =20
=20
> I was basiclly saying "yes, this is possible, BUT, in he delay =
between
> your DO and your friend's SEE another DO might occur that changes =
the
> SEE - so and UNDO might be needed".
>=20
> If we are talking of locking everything down, then an UNDO isn't =
needed,
> I agree with this.
Not everything -- only "important things". So the question -- if =
authors
lock only "important things", would undo abilities still be needed?
> If you lock objects down, this works, but you can also crsate
> worlds where things occur and you handle the conflicts at a later
> time.
Yes, I agree. Are there any language extensions that are esquired
to help authors control undos/ conflicts, etc. Like maybe a fence --=20
"undo-only-to-here-but-not-earlier" primitive?
=20