Wednesday, September 29, 2004

Jasmine Status

Andreas and I are working toward a release of "Jasmine" for Saturday. The major difference is that the TeaTime architecture will not be part of it. Why? This is a very good and deep question. The major reason is that Solar works so incredibly well, and everything we have done so far that uses a TeaTime/TeaParty like architecture is surprisingly slow, except for David Reed's version, which isn't quite done. So what we are doing is the following:

Moving Solar to the Squeak 3.6 image. This gives us a better
environment to develop in. Andreas wants to skip 3.7 and move the
system directly to 3.8 when that is available.

Upgrade the OpenGL rendering model. This is a much nicer interface.
Also, the OpenGL object is only passed to the rendering object at
render time, hence there is no need for global updates of it when it
changes. Overall, a big win. This also means that the initialize
methods are greatly simplified and since #initialize is now always
called by default inside of #new, this clean up the code as well.

Keep the current Solar #step model. This is the major difference
between Solar Croquet and Mad Hatter (as far as the component code is
concerned).

Upgrade the remote object construction. Currently, this does not allow
nested calls to metaConstruct. For that matter, any nested meta is a
bad thing. This change will allow you to call any meta inside of any
other, hopefully without too much trouble. This SHOULD lead to making
the 3D CAD system I built (see below) truly collaborative.

Synchronization of TObjects. This is everything from copying your
avatar over to the remote machine to copying entire spaces. This may be
in a later release, if we can't quite get it done this week.

Multiple TeaParties. This depends upon the synchronization. Currently,
Solar can only deal with a single TeaParty at a time.

Morphic,Linux, Windows, Mac 2D collaboration. This will be done using
the remote frame buffer (RFB) courtesy of Ian Piumerta. The way this
works is you have a single master component that renders the 2D buffer
and ships it over to the slave components on the remote machines.

From a component view there is one MAJOR difference between Jasmine and
Mad Hatter. In Jasmine, the programmer will have to explicitly deal
with synchronization. That is, the system will not automatically ensure
that messages are sent and executed at the right time, for that matter,
it doesn't guarantee that they are sent at all. It is totally up to the
programmer via the meta messaging architecture I did. There are pluses
and minuses to this approach. On the one hand, the programmer has a lot
more control over what is communicated and when between replicants. On
the other, the programmer has to take control of this and must have a
much deeper understanding of the nature of how the object should stay
synchronized. I did a search for "meta" and "metaSend" and was
surprised by how few of these messages actually get sent. But of
course, it isn't the number of them, but their strategic location in
the code. Further, we won't support multiple teaparties to start, but
should have them quite soon.

I am not certain about this, but I believe that components written in
Jasmine will port to Mad Hatter with no changes and will work
essentially identically, however, there are a number of components that
employ a different strategy between these two models. First, there is a
push update model, as employed by the Mars Rover. This is a
master/slave architecture, where the master broadcasts the current
rover state to the slaves. In this case, the master is determined by
whoever interacted with it last. The second is a pull model, not yet
implemented, that could be employed by the flag (a 3D flag waving in
the breeze). The way this would work is the flag would not update
unless it was being rendered. When you first see it, it will send a
message to all of the peers in the teaparty asking for whoever last
touched it and getting that value. There are some other different
approaches to this as well. Also, time synchronization is much less of
a priority in Jasmine. Messages are still time stamped and sorted, but
they are executed immediately. I plan to implement my simple time model
on top of this, which should dramatically improve robustness.

3 comments:

Anonymous said...

Any chance on when Jasmine is to be released by? I like a lot of others am anxious to play with the product.

Croqueteer said...

On Monday - really...

DAS

tak said...

David,

Would you consider that developing the Chain Reaction is based on Jasmine? Now I assume it is based on Mad Hatter, but I think performance is the most important issue in the game. So I wonder if it is better to adapt Jasmine. Besides, debugging on current TeaTime is not easy.

If you think the project aims the demonstration of new style of network programming, we should keep on TeaTime. But if you think we will release the project by several months, I think Jasmine is better.

Takashi