DesignPatternsPoint5

In 0.4 there were two kinds of communication: client-server, and client-client. The latter was used when there was no reason for a client to inform the server about any significant (e.g. persistent) change of state. It's exemplified by Jon in the example 3-boxes cell.

In 0.5, all messages from the client go directly to the server (so there is no more client-client communication). The server then explicitly resends these messages to the correct set of clients, using channels or other mechanisms. So, to mimic the 0.4 client-client communication in a new cell, the developer needs to create the code so that the client sends a message to the server cellMO (or 'CellGLO' in 0.4-speak) and the developer also creates code in the cellMO to redistribute the message to other clients.

In 0.4, there were also two patterns for client-server communication. The first, exemplified by Jon's 3-boxes example was thus: the user interacts with a cell on client A; the cell updates its state/display and then sends a message to the server; the server sends a message to all other clients (except client A); when those clients receive the message they update their state/display. This was the template for most client-server communication, the benefit is that the initiating user sees the result of his/her interaction with a cell immediately. However, there was a second pattern used by many of the collaborative apps (such as the movie player), in which the initiating client made no immediate change to its state/display; instead it sent a message to the server, which then sent a message to all clients, including the initiating client. The benefit of this approach was that it was easier to synchronise all clients (plus the benefit that the initiating client didn't need a special call graph to handle updating itself first).

In 0.5, due to a change in darkstar, it is no longer possible for a cellMO to send a message over a regular channel to a set of specified clients. The message is sent to all clients. It's therefore the responsibility of the client receiving a message to decide whether to ignore the message. And it is especially important for the client who sent the message to ignore the message when it echos back if it has already processed the changes locally.

Also, as an aside, the conventional app sharing (X, VNC, etc.) in 0.5 will still use P2P communication.