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