Package talx.model

Provides state information for the entire application, and access to the transport system.

See:
Description

Interface Summary

GUIStateConstants	Constants used to interpret the GUIState object.
StoreListener	Contract for listeners of store and transport usage events.

Class Summary

GameManager	This class holds all games that are currently being played, as well as reading in and writing out their corresponding states.
GameState	Holds the state of a Game.
GUIState	Holds the entire visual state of the system.
Person	This class represents people on our email mailing list.
Player
Settings	This class reads in a given XML file and parses it for a variety of values which it will store in its private variables.
TransportToolkit	Provides the message store API.

Package talx.model Description

Provides state information for the entire application, and access to the transport system. The model components can be divided into three catagories: volatile, non-volatile, and reference.

The Volatile Model Components

There are two volatile model components: game states, and GUI states.

The game state objects hold the state of a game currently being played. The objects are held in the game object and passed around between the game view and the game handlers to update and display the game status.

The GUI state objects hold any volatile information needed to operate the system. Since all controller and view components are prohibited from keeping state information, all state information needed by a view or controller object must be held in a model object. The GUI state structure is such that it can hold arbitrary data.

The Non-Volatile Model Components

The non-volatile state information is held in the settings object. The settings object contains a well-defined set of visual and behavioral hints that are used by the view, controller and model reference components to customize the system for the user. Changing the settings object is not a reliable way to alter the system's behavior because components may only read the settings at startup as an implementation detail.

The Reference Model Components

There are two reference model components: the transport toolkit and the game manager.

The transport toolkit provides a gateway to the mail delivery system. The transport toolkit sits in the middle of the mail delivery system and supports two listener types to track changes to the underlying message store.

The game manager provides an entry point into the Games Service Provider Interface (SPI) and provides the long-term persistence mechanism for game state objects. The game manager uses SPI architecture to connect game providers to game requests. The games package contains all of the game provider framework. Actual game service implementations are provided in vendor-specific packages. (See the games package for more information about the Games SPI.)

The Transport System

The transport system represents the set of mail messages available to the application. The transport system provides transport services and stores the current set of messages. The transport system may be updated at any time due to messages arriving asynchronously. The transport system consists of the incoming filter stack, the outgoing filter stack and the transport toolkit.

The Incoming Filter Stack

The incoming filter stack usually has a RemoteReceiver at the top, which gets messages from an outside service and sends them through the stack. The bottom of the incoming filter stack is the TransportToolkit object. When messages arrive, they are packaged as events and sent through the stack's new message pipe. Each filter decides to continue sending the event through the new message pipe or the filtered message pipe.

The Outgoing Filter Stack

The outgoing filter stack has the TransportModel object at the top and usually an SMTPSender at the bottom. The TransportToolkit exposes an API that allows message generation to the stack. Messages are delivered to the stack as events through the send message pipe. Each filter decides to continue sending the event through the send message pipe or the filtered message pipe.

The Message Store

The message store is encapsulated in the transport toolkit. The toolkit exposes an API that allows messages to be added, removed, moved about and retrieved from the store. Features and view components that want to know about transport model changes can subscribe to the toolkit object.