SST itself specifies little in terms of policy for distributed application behavior. Rather than hard-coding such concepts, SST uses collections of pre-defined or dynamically created configurations for the various components.

As a user, creating new configurations will not be required. Instead you will use one that has already been created for you by a developer to match particular aspects of the design for your distributed application. Different configurations will provide you with different system behavior.

Configurations are declarative descriptions of behavior. They can be likened to control blocks which give detailed descriptions of how an object is built and executed. They provide an easy way to manage frequently used setups.

Configurations are especially useful in frameworks where component implementations (and thus parameters and settings) vary widely. The framework need only supply configure API where the implementation specific configuration objects are passed to the component being configured. The framework need know nothing of the actual number or content of the settings--it simply passes them along.

Typical users need not know much about the configuration of standard SST infrastructure components. Infrastructure configurations (invocation handler, marshaler and space configurations) are mechanisms for harnessing flexibility rather than something which is frequently programmed. Once your application's infrastructure requirements are encoded in configurations, they can largely be ignored.

Several infrastructure components (invocation handlers and transports) manage repositories of pre-defined configurations which are automatically used by the system. For example, the scheme and transport elements of a URL are mapped onto sets of invocation and transport configurations. In this way, the specification of a complete set of SST infrastructure and its configuration is given by a URL such as: myScheme:/tcp/foo.com.

Configurations for non-infrastructure elements of SST (such as Actors) are different. Typically, they are used more frequently and directly. In some cases, the use of configurations is the primary way of creating the objects they configure. To this end, all configurations support instantiation protocol of the form: instantiate, instantiateFor:, and so on. For example, the new class method of Actor is implemented as: ^self defaultConfiguration instantiate which creates a single-threaded Actor according to the specifications of the default configuration. Different configurations are used to create Actors with different behaviors.