The major purpose of this distribution is to add timestamp support for
multimodal interaction, complete and document a number of new features, and
tie up loose ends.
Broker proxies
In 4.0, we've introduced a powerful additional API for brokering which
has significant advantages over the old one. It relies on an encapsulation
of broker contact information called a broker proxy.
This new encapsulation is a distinguished data type, so brokers can
be reliably recognized in frames, unlike the old API, where the contact
information was scattered throughout the frame. This makes it possible for
code to identify brokers reliably, which means that it's now possible to
write general-purpose firewall bridges.
The distinguished :call_id key for uniquely identifying
the broker data is encapsulated in the proxy, so that it's now possible
to insert multiple broker references in the same message.
The new API supports writing objects to and reading objects from
broker proxies without callbacks if you prefer.
The new broker proxies include type information, so that the receiver
can reliably distinguish between, say, an array which is a portion of a
larger array and an array which is intended to be self-contained.
The new broker API supports either immediate or delayed invocation
of the data handler callbacks on the receiving end, and in the delayed case
accumulates the data for you.
We recommend that everyone upgrade to this new broker API.
The old broker API remains unchanged, and will continue to be supported;
in fact, the new broker API is implemented entirely in terms of the old
one.
Timestamps
To support the synchronization of multimodal input, we've introduced timestamps into the Hub.
Provider names
In 4.0, we have expanded and rationalized the way the Hub can refer to
specific service providers. Most significantly, we have introduced a system
of provider names in the Hub, which
can be specified, retrieved, passed around, and targeted for messages. We
have also made this expanded syntax available in a wide range of Hub program
directives.
Hub GUI
In 4.0, we have finally completed the Hub GUI message set and implemented
a simple reference which is included in the distribution. The Hub can establish
contact with this server using the -gui command line argument,
after which all status messages which would have been routed to standard
output or standard error are sent as message frames to the specified server.
This server can use this information for profiling or visualization.
Listener-in-Hub API
In 4.0, we've constructed a new server-side
API which provides a structured method for contacting the Hub when that's
all you really want to do.
Windows support
In 4.0, all executables, examples and demos are compiled for Windows, and
the tutorial runs on Windows as well.
