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.
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
be at the point just before he tried to pick up the wallet.
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.
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
University of Minnesota 100 Union St. SE
email: [email protected] Minneapolis, MN 55455 USA