The Message Passing Architecture

 
 
 

The Showcase Message Passing Architecture consists of the Message Queue, a Message Dispatcher and the Showcase Interpreters, as illustrated in the following diagram. These operate in the larger context of custom add-ins, and the running Showcase application with loaded scenes and models.

The simplest way to understand the Message Passing Architecture is to follow a Message as it moves through the system:

  1. The add-in sends a message to Showcase following the established protocol. For example, to trigger a built-in menu item, the add-in would use the MENU_INVOKE_ITEM Message.
  2. The Message is automatically placed into the Showcase Message Queue, along with Messages from other add-ins, and Showcase itself.
  3. At the beginning of each re-draw, the Message Dispatcher services the queued Messages, passing them to the Showcase interpreters.

    Showcase makes use of a number of built-in interpreters, responsible for carrying out the actions indicated in the Messages. This is transparent to the add-in developer.

  4. Response Messages flow in the other direction: from Showcase to the add-in. They are used to provide an indication of success or failure of the task to the add-in.

    It is the responsibility of your add-in to listen for Response Messages. Since the Message Passing Architecture is asynchronous and frame-based, it should not be assumed that an action has been carried out simply because your add-in has issued a Message.

Note the following:

For details see Sending Messages.

Message Types

There are three kinds of Messages:

  1. Action Messages: These messages instruct Showcase to carry out a specific action.
  2. Response Messages: These Messages are sent by Showcase to the add-in to indicate its instructions have been carried out.
  3. Information Messages: Messages that present additional information to the add-in or request additional information from it.
Note Typically, add-ins issue an Action Message, then wait for a Response Message before proceeding. If your add-in issues an Action Message to delete a scene object, for example, it should wait for confirmation that the object has been deleted before continuing.