THESIS PROJECT My thesis project is support for better group interaction in Open Cobalt. It's what I've been working on the past year, so may as well make it official. There are several components to this we've discussed, and are in various stages of implementation: - Useful group text chat - Touring spaces as a group - Sharing a virtual experience in real time The last one is particularly interesting, I think. It would be the virtual equivalent of "coming over to watch the game", only much more immersive. The means to implement that would be an "overlay island" that comes with 3 features: - A private text chat channel - A private voice chat channel - A private "overlay space" The overlay space would be, at it's most basic, a real time clone of the original space the group wishes to share a private experience inside. Imagine, for the purposes of illustration, that the group wants to watch a presidential debate together. The group is of course not permitted to crash the debate and have a rowdy party in public in front of the entire nation. However, in their own private instance of the debate, they are free to do whatever they want, including: - discuss each candidate's points, as loudly as desired - create some whiteboards beside each candidate and keep track of what is happening - put a web browser in the space and watch what is happening on twitter and Wikipedia - Create and sit on a large couch anywhere in the debate hall. - Throw things at the candidates - Draw a mustache on the avatar of the candidate they don't like, or dress him in a pig suit - replace the stage with a courtroom to imagine that one candidate is trying the other for crimes - get naked and depict illicit sexual activity with or between the candidates. - you get the idea All this will be private to the participants, and the people watching the debate through its public channel will not be able to see any of this; unless the operator of the overlay island lets them in. The debate is still happening normally; the group is merely augmenting their shared private instance of the debate in their own private overlay island. Anybody can thus augment any space with their own customizations in their own overlay, and have real privacy in a public virtual place. In theory, you could create such an overlay atop second life places or web pages as well. There could be a mechanism for the people in the private overlay to relay messages back upstream to the larger event. In a more serious setting, the overlay could be populated by people from a particular interest group who have questions for the candidates. The group could discuss questions and vote on them, and the best ones could be forwarded upstream (manually or automatically) for the candidates to answer, while the interest group watches, talks, and has virtual tea and coffee. A similar mechanism could be used to move an object in an overlay to the upstream space for everybody to see. Overlays can also be nested, so that if the interest group gets too big, a smaller group can work in private in the midst of the larger group. There must be a mechanism to control which island you are talking within at any given time, whether the public event, the larger overlay, or the smaller overlay. Overlays could also be used to allow a team to construct a complex build and test it at a specific location, then quickly bring it live when it is showtime. Again, anybody can create an overlay at any time atop any space they have access to. For maximum flexibility, an overlay should probably be stored as the relative difference between two spaces: what objects were added, removed, and how the remainder were modified. It should be possible to move things between overlays using a merge operation, much like branches in a version control system. On the other hand, such a mechanism may be better treated as orthogonal to overlays. A space could be composed of multiple layers, as in Photoshop, where each layer can modify the ones below it. An overlay would merely be a mechanism to add private layers to a public space. Layers could be used as ways to work on different parts of the space in isolation. They could also be used like a changeset history in a version control system. That's is I want to work on for my thesis project. IMPLEMENTATION This is in theory straightforward to implement within the cobalt framework. Just allow routers to be clients of other routers. An upstream router will service the standalone space, a downstream router will service an overlay. Every node in the tree will see updates to the root island, but only children of the overlay node will see updates made in that island. The renderer will need to be modified to render objects from multiple islands (and layers) into a single scene. This will probably be harder than necessary, given the ugliness of the renderer code. I'm doing a little bit of simplification to the renderer code now to make this easier later. In order to implement tour groups, and to have a way to control what island one is talking to, the cobalt event system needs to be made more understandable. There must be an easy way to specify the destination island and layer (for overlays), and the destination of navigation events (for tour groups). I'm doing a bit of simplification to the event system currently, as well PROGRESS THIS YEAR In November 2009, I started talking to John and Andreas about how to best port Cobalt to a recent squeak version. I originally thought I'd port to Pharo because of their better packaging support, but then Andreas released Teleplace Tweak for Squeak trunk. Since porting Tweak would have been one of the major challenges of the port, I decided to adopt this work and change my porting target to Squeak trunk. I thought I would do this during my vacation at Christmas, but I didn't. By February 2010, I had a Squeak trunk image with Cobalt Tweak and Teleplace Tweak fully merged, and an unmodified Cobalt system loaded atop it. When I tried to start Cobalt, however, I learned that the method we have been using to start Tweak is very old and obsolete, and no longer worked on Teleplace Tweak. I asked Andreas about this, and he told me that they had completely changed the way they start Croquet at Teleplace. They start Tweak, and run everything under Tweak. Croquet is just an application running on Tweak at Teleplace. He gave me the code. Using the code would mean completely changing the interface between Cobalt and the base system. However, as I said above, I need to simplify the event system and the renderer to do my thesis project. Adopting Andreas's code would give me a head start doing both those things. It means that the port to Squeak Trunk is now going to take longer than it would have, had I just patched the broken parts of the obsolete Tweak code. However, I decided to adopt Andreas's approach because it would give me a head start on my thesis; forcing me to learn the existing event and rendering systems enough to simplify them and put them on this new base, rather than the old CobaltBrowser/CobaltHarness base. That's what I'm currently working on. I have a minimal Tweak space that runs by itself, and a mechanism to start Cobalt and show it inside Tweak. It doesn't yet bring up the space as fully as it should, doesn't load an avatar, doesn't put the camera in a useful position, and doesn't let you interact, but it's a start. Once it is finished Cobalt will be in a much better position to explore deep modifications to its internals, such as what I want to implement for my thesis