Hey all, millimetering ever-closer to a squeak plugin to SL. The pattern 
is quite simple:


start second life.

add a texture to a prim in SL that points to a localhost server with 
appropriate mime type.

have a plugin available for SL that  can share a memory buffer with a 
cobalt instance.

Tell Cobalt to render into that instance with appropriate channels for 
mouse/keyboard I/O.

Tada: Croquet/Cobalt on a prim.

The Teatime architecture appears to be the ultimate P2P plugin tester, 
but its only being used for the rather huge Croquet/Cobalt use-case.

Now, this is going to be fun, and possibly useful, but for most users of 
SL, Croquet isn't going to be all that attractive, at least at first. In 
order to get a foot in the door, I want to establish a TObject which 
renders to SL, accepts I/O from SL and broadcasts it to other TObjects 
connected to OTHER SL clients.

This turns squeak into a media plugin prototyper for SL AND opens the 
door for more interesting plugins, such as ones that generate 3D data 
(not necessarily in Croquet format) for injection into SL.

The same pattern could be added to any kind of chatroom. The ultimate 
form would be having a Croquet/Cobalt window embedded in an IRC or 
Google Wave window, but more limited object sharing should be quite 
useful (often more useful given the overhead of a complete Croquet world).



So, my question is: how do I strip TObjects/Teatime away from the rather 
huge Croquet context, so that I could do a hello world example of a 
simple TObject rendering to a SL media plugin and sending updates to 
other TObjects connected to other SL clients via the media plugin?

The sky is the limit for this functionality, IMHO. Croquet is only the 
sexiest example, but in fact, I don't think its the most practical. The 
hello world TObject is much easier to grasp the implications of, because 
"rendering" can be replaced with ANY object-state transfer to the target 
application (which could be anything, not just the Second Life client).


Lawson