Chapter 26. Sending and Receiving Data with Storyboard IO

Table of Contents

Storyboard IO Transport protocols
Connecting to a Storyboard Application
Sending Events to a Storyboard Application
Event Naming Conventions
Serialized Data and the Event Format String
Setting Application Data
Receiving Events from a Storyboard Application
Debugging Storyboard IO
Debugging egress (Storyboard Engine sending to backend)
Debugging ingress (Storyboard Engine receiving from backend)
Storyboard IO Utilities
iogen
iorcv

The Storyboard IO API, formerly known as GREIO, provides a platform independent communication API that allows inter-task and inter-process queued message passing. This is primarily used to allow external communication with a Storyboard application.

The API provides transport delivery guarantees for messages that are placed into the queue regardless of the implementation. The maximum transport size of a message and the total queue capacity varies slightly from implementation to implementation however a 2K message size should be considered a design limit with the practical implementation limit around a 4K message payload size.

Storyboard IO communicates events over a named uni-directional channel. By default, Storyboard applications have a receive channel, named after the deployment bundle file (i.e. [bundlename].gapp). This allows backend applications to send events to the Storyboard Application. A custom receive channel can be specified in the command option for sbengine. The Storyboard application can transmit events on one or more channels. The backend software will need to open the channel and listen for events. See Storyboard IO API for more details.

Storyboard IO integration with the Storyboard Engine is implemented as a plugin. It is possible to create alternate Storyboard IO implementations that take advantage of custom communication facilities available on a platform.

The Storyboard IO plugin provides a single communication channel which clients can used to inject events into the Storyboard application. These events will be queued and dispatched in the same manner as internally generated events.

Client applications can use Storyboard IO to create their own communication channels and then receive events from that channel from the Storyboard application or from any other Storyboard IO client.

Storyboard IO Transport protocols

The Storyboard IO API layers on top of native message passing and communication APIs, dependent on the operating system:

Linux

SysV message queue

MacOS

SysV message queue

QNX

QNX POSIX message queue (mqueue server or mq server/library)

Using the SBIO_MQ_PATH environment variable you can determine which message queue technology will be used. By default the standard mqueue server and corresponding C library mq_* functions will be used.

If the SBIO_MQ_PATH environment variable is set to point at the libmq.so library (i.e. SBIO_MQ_PATH=/usr/lib/libmq.so) then the default binding for the message queue implementation can be changed to use the mq server and the corresponding mq library functions.

If the SBIO_MQ_PATH environment variable is used, then it must be used consistently with all Storyboard IO clients and servers that want to communicate with one another.

WinCE/WinCompact7

WinCE MSMQ

Win32

MS-Mailslots

RTOS (FreeRTOS, MQX, ThreadX, etc)

In memory queue