Re: [vwrap] #12: Event-like resource type for LLIDL

[Lawson English <[e-mail]>]

Carlo Wood wrote:
> I'm not sure if I follow what an "event" is.
>
> [...]
>   
> means that upon a request the sim will not reply with a responding
> state, but merely with an ACK, then the requesting host has to remember
> the operator and apply it on the state at the moment he receives the
> acknowledge.
>
> For example, host1 requests R1, then it receives the update R2 and
> finally receives the acknowledge for the R1 request.  Clearly it
> has to apply the operators in the order: first R2 then R1.
>
>   
You might want to look at the Teatime architecture as implemented in 
Croquet/Cobalt for one way in which this is handled. Each user of a 
Cobalt "client" initiates an event in its own copy of the 
simulator-client, which sends the event to the central authority, which 
in tun broadcasts that event to the shared simulation in the order that 
the event is received. The unique thing about Cobalt is that every 
simulator is running on the same virtual machine with 100% identical 
behavior at the ISA level and the "events" are standard Smalltalk OOP 
programming messages sent to the copy of each smalltalk object as though 
they were receiving messages directly from another object locally.

No event is recognized in any client-simulator until it is authorized by 
the central dispatcher, not even the client where the user chose to 
initiate an avatar movement can render it taking a step until the 
dispatcher broadcasts that event and it is received by each client. One 
upside is that only simple OOP messages are sent, often with less 
overhead per event than sending large amounts of state data. One 
downside is the requirement that ALL clients' simulators are running 
100% identical byte-code interpreters, along with a programming model 
that assumes that all objects are collaborative whiteboards (with some 
exception made for handling avatar actions I'm guesing) so the shared 
illusion of a SL life economy is virtually impossible, under anything 
resembling the current Croquet/Cobalt implementation.

http://opencroquet.org/index.php/Overview
http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf
http://opencroquet.org/index.php/Croquet_SDK


However, there is room for _ad hoc_ implementations of Teatime or 
Teatime-like services in a VWRAP metaverse. Consider the obvious 
use-case of a genuine in-world collaborative whiteboard that uses 
Croquet/Cobalt teatime (or something similar) as the collaborative 
networking architecture to share drawing commands between MoaP objects. 
People could subscribe as collaborators and indulge in 100% coordinated 
interactions in any level of sophistication, or they could subscribe as 
the audience and simply observer the interactions, perhaps via a 
broadcast read-only VNC session or a readonly teatime equivalent.

The interactions could range from simple drawing apps ala the flash/java 
based whiteboards you see on webpages, to more complicated setups like 
Kansas (written in Self)

 http://research.sun.com/ics/kansas.html

or Nebraska (a partial port to Squeak smalltalk) 

http://wiki.squeak.org/squeak/1356 

implemented on prims in-world or in proximity-sensative HUDs or even as 
some kind of ghostly physics simulation  where physics and other 
behavior is controlled by a different  setup than the normal central 
VRWAP server or as special physics/combat interactions governed by 
client-side simulations.

Squeak smalltalk was chosen for the implementation of Croquet for 
several reasons, including fast prototyping but also because it 
implements  100% identical VM behavior cross-platform (including 
floating point calculations) which is vital for maintaining totally 
coordinated shared simulations using distributed programming. It should 
be easily possible to use the Croquet/teatime/Cobalt island system to 
control simple objects (e.g. whiteboards and combat-physics simulators) 
using embedded squeak (suitably sandboxed to only generate safe 
messages) or in circumstances where 100% identical behavior is not 
needed, other languages and strategies could be used instead.

The demo project I'm working on would take an existing Cobalt world and 
render it on a prim using a simple modification of the Media plugin. 
This would allow for amusing things like teleconferencing between 
different virtual worlds. More practical scenarios would be to use a 
similar strategy to implement whiteboards ala Kansas/Nebraska, combat 
systems, shared line dancing, music collaboration, etc.

The pattern (assuming Squeak here, though you can do it with less 
precise coordination using other languages and systems):

SL client <=> media on a prim <=> [rendering/keyboard i/o to Cobalt 
world-client] <=> teatime/cobalt island dispatcher/event handler <=> 
[Cobalt world-client  interactions with rendering/keyboard i/o] <=> 
media on a prim <=> SL client


Put any kind of event handler/generator you like in the [ ], and you 
have, at least for those specific events, potentially 100% identical 
behavior even in a VWRAP metaverse.

Note that the SL client  would consume and generate events 
(images/keypresses/combat messages/etc) sent to the teatime system but 
that aside from these specific points of interaction, the slavish 
control of a Cobalt shared world woudn't be implemented, leaving the 
more liberal behavior of a VWRAP world intact. If a client doesn't get 
the message that a drawing was done, or that a dance step isn't to be 
initiated or that a physics simulation for ghosted prims hasn't changed 
their state, it only affects the specific view of that aspect of the 
shared simulation, not the entire simulator's.


Lawson