When the application starts the Core is uninitialized and must be explicitly initialized by the programmer. The initialization process is responsible for proper Core start up which includes instantiation of the requested global objects, their registration and initialization. To simplify the process and shadow the programmer off the initialization internals and subsystem dependencies as much as possible the Core defines a Massiv::System::StartUpInfo structure that drives the initialization process. As a result the Core can be started by a single call to the System class.

The StartUpInfo structure contains information that describe what subsystems will be required by the application and optional parameters that can affect the operation of that subsystems.

Note

Since the Massiv is an extensible pluggable system and not all applications generally require all of its subsystems, there is a way to specify what subsystems should be started. The system then resolves the start up dependencies (what already must be and must not be running when a specified subsystem is being started) and ensure the proper start up order. Although it is not currently used, the initialization process allows for subsystems reinitialization or restart at run-time.

The structure can either be filled by hand (the knowledge of the Massiv Core Reference Guide is highly recommended) or automatically according to a predefined application profile. Currently the profiles are classified by node types, there are profiles for anonymous-only nodes, client nodes, server nodes and data service nodes.

	Note
	Anonymous-only nodes can be used to implement support utilities only as nearly everything is not available. For example the Massiv filesystem utilities (see Chapter 25, Auxiliary Utilities) run under this (modified) profile. An application programmer should be interested in server, client and service profiles only.

To construct a StartUpInfo structure from a profile, use the following constructor:

typedef void RegisterClasses();
typedef void CreateNodeObject();
typedef void NextTick();
...
StartUpInfo::StartUpInfo
  (
  Core::NodeId::Type  node_type, 
  const std::string & conf_file, 
  RegisterClasses *   register_classes = NULL, 
  CreateNodeObject *  create_node_object = NULL, 
  NextTick  *         next_tick = NULL 
  );

	This determines what profile will be activated. The Core defines the following values: TYPE_SERVER, TYPE_CLIENT, TYPE_SERVICE and TYPE_ANONYMOUS. Their meaning should be obvious from the text above.
	The path to the main configuration file. May contain $HOME shortcut that will be expanded to current user's home directory.
	The callback whose purpose is to register all managed classes that the local node supports. Usually points to Massiv::Generated::register_classes() generated by the IDL compiler. The callback is fired at system initialization. See description of class_list command in Section D.2, “The idl.list File”.
	When the local client or server node connects to the simulation, an object level representation of the local node should be created. The callback is responsible for instantiation of an application defined class that inherits from Lib::NodeObjectInterface and represents the local node. See Section 14.2, “Node Object”.
	Callback invoked by the Core at the end of each tick. Note that the SRPC can not be called from within the callback.

The constructor takes a parameter that describes what profile should be used, path to the configuration file and optional callbacks. The callbacks are automatically registered when the structure is used to drive the system initialization. However they need not be specified in the structure. In that case they must be registered explicitly before the system initialization.

Note

The callback registrations are global and are not part of the system state. It means that they must be registered before the system initialization (it can be done automatically through the StartUpInfo) and are not reset when the system shutdowns. They also can be registered only once and cannot be unregistered or changed for other callbacks later. Use System::register_register_classes(), System::register_create_node_object() and System::register_next_tick() to register your callbacks. There can be more callbacks registered to the same type of the event.

To initialize the Core do the following steps: