Things to do:
Jasmine is a simpler version of the Croquet architecture intended to
act as a stop gap until the TeaTime version is released. It may be
unnecessary, but I think a lot of the ideas in it will be recycled into
the TeaTime version anyway. I worked hard to make it so that both
versions use the same object models, so any changes in one should be
easily replicated in the other.
- Get the TParty architecture to work properly. Currently waiting for Andreas Raab to fix a bug that causes the system to freeze up. The TParty is actually what the E Language people refer to as a VAT . That is, a collection of objects in a computational subworld that you can only have indirect access to. There are a number of very nice things that Andreas did to make this work. First, every Vat has it's own
independent process, which should make it quite easy to add my lightweight TTime model to it. Second, the entire Vat is easily checkpointed, or streamed out, and resurrected.
- When we do a checkpoint of a TParty, we need to replace the external
TParty references with something useful when we ultimately resurrect
the TParty. Currently, there are three kinds of objects that we need
to deal with that exist in external TParties. The first is the TAvatar
- or the representation of the users in the space. These objects are
transient, hence they need to be simply removed upon a checkpoint. The
second are the portals leading to external spaces. We will be replacing
these with an imposter TSpace object inside its own TParty that looks
like the original, but is much lighter weight. Think of it as a 3D
snapshot. The third kind of object are the TForms inside of the
TTextures. These need to be replaced by the TForm thumbnails when we
- The imposter space maintains a reference to the real space on
another machine. Until the imposter is forced to be rendered (or
touched in any way by the user), it begins the process of downloading
the real object space using it's internal reference. Once the real
space is loaded, the imposter space will replace itself with the real
version. The imposter space lives in its own TParty.
- The thumbnails work the same way. They live in their own TParty.
When they are used in any way, either rendered as an object, or used as
a texture on another object, the thumbnails begin the process of
loading the real texture.
- Since textures are static objects, we can cache them in a global
server somewhere. That is, when you construct a space and use a new
texture in that space, this texture can be written to an external
server. When the space that uses this texture is shared, a reference to
the original texture on this server is also shared. When a texture is
downloaded from the server, it is placed both into the space replacing
the thumbnail and onto a local cache on the disk.
- The next big thing is the actual TTime model. This is well described
in a white paper I wrote, which is unpublished. I need to reread it
before posting anywhere, but this will proceed without the rest of the
This is the "real" version of Croquet. It looks like it may see the
light of day before I actually complete Jasmine, which would be
wonderful - though I intend to continue work on Jasmine if only because
it is a simpler model of the system.
- TeaTime requires the same texture caching mechanism as described
above for Jasmine.
- Need to test out a more massive environment to determine the cost of
- Fix up all of the demos. Rework them into the appropriate
Teaparties. Each demo space really needs to be in its own TeaParty.
- Debugging of course.
The current documentation for developing in Croquet is in very poor
state. I need to completely rethink this - though I would like to have
something in the next three or four weeks.