Now Complete Msg!! Was: Behaviours (Was: Re: ADMIN: VRML + JAVA - A Wedding)

Master Zap ([email protected])
Thu, 19 Oct 95 12:47:09 -0500


-- [ From: Master Zap * EMC.Ver #2.5.02 ] --

The end of this message was lost....and lost, and lost.

Now I've cracked it. It should be lost no more. (Fingers crossed...)

[If you want to know, the problem is a PERIOD on an exact special positon on
a line. This period gets line-wrapped down to a line of its own, and a
period alone on a line means "end-of-message" to some mailsystems. ... I
HOPE!]

*HERE* is the lost part:

> 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 also bends down, picks it up. As far as Barney is concerned
> Barney got the wallet.

In my model, Fred would have to send a pick-up message to the wallets brain,
before he can actually get it, and so would Barney.

Basically, in this case, the person with the least lag to the host running
the brain for the wallet would win. But it would never be inconsistent.

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

I think you are solving a non-problem. The picking-up itself must be
authenticated by a single control-point, IMHO.

But your "undo" ideas fit into another are where they MUST exist. If you
esad my proposal (my web page, click the top) you see I suggest time-stamped
messages. And I even suggest time-stamped messages into the FUTURE. Which
also allows OVERRIDING timestamped messages.

Which means, that if message A arrives, saying that the vase that is falling
to the floor right now should shatter in 0.8 seconds (which is a
predetermined "future" timestamped message). But say somebody catches it
just before it hits the floor. Then a new message is sent out, basically
saying "cancel that, the vase was caught at time so-and-so".

But what about the browser at the other end of a .9 second lag? The vase had
alesady struck the floor (and shattered), and THEN the message "no, it
rsally didn't" arrives!!

Your UNDO ideas is very much needed here!!

> --------------------------------------------------------------------------
-----
> -
> Neophytos Iacovou Distributed Computing
Services
> University of Minnesota 100 Union St. SE
> email: [email protected] Minneapolis, MN 55455 USA
>

--
Hakan "Zap" Andersson | http://www.lysator.liu.se/~zap | Q: 0x2b | ~0x2B
Job:  GCS Scandinavia | Fax:   +46 16 96014            | A: 42
[email protected]    | Voice: +46 16 96460            | "Whirled Peas"
------------------------------------------------------------------------
The moon is better than the sun, beacuse the moon shines when it's dark.
                                                       - Me
------------------------------------------------------------------------

------- FORWARD, End of original message -------

--
Hakan "Zap" Andersson | http://www.lysator.liu.se/~zap | Q: 0x2b | ~0x2B
Job:  GCS Scandinavia | Fax:   +46 16 96014            | A: 42
[email protected]    | Voice: +46 16 96460            | "Whirled Peas"
------------------------------------------------------------------------
"There I was, driving at the speed of light, when I accidentally 
 turned on the hsadligts, and the light piled up on the windscreen 
 like wet toilet paper...."
------------------------------------------------------------------------

  • Next message: Timothy F. Rohaly: "Re: BNF"
  • Previous message: Master Zap: "Wasting bandwith about: Re: bandwidth wasting :-)"
  • Maybe in reply to: Master Zap: "Behaviours (Was: Re: ADMIN: VRML + JAVA - A Wedding)"
  • Next in thesad: Wayne Ingalls 206-865-3593: "Re: Behaviours (Was: Re: ADMIN: VRML + JAVA - A Wedding)"