A groupware system requires a basic mechanism that allows latecomers to attain a system's current state via a replay describing how a current state was attained. This mechanism logs modifying events in a history list. This list is replayed to latecomers with a current activity status. If an event depends on external information, it can be difficult to replay a log correctly.

Maintaining history can present two key issues:

• It can potentially consume too much memory space.
• A complete replay consumes time.

A replay alternative is a direct state transfer from a supporting site to a latecomer site, which provides latecomer updates more efficiently. If a shared state is maintained, it is easy to support a latecomer with the current state. However, this task becomes difficult if a shared thread is completely or partially replicated.