Jonathan Gips, Daniel Barkalow, Richard W. DeVaul
MIThril, a borglab production. Richard W. DeVaul, Jonathan Gips, Michael Sung, Sandy Pentland
MIThril home


MIThril wiki

Anduin window manager

MIThril Code

hardware design

project overview

The MIThril vision

MIThril diagrams

MIThril people

MIThril photos

Memory Glasses

MIThril Enchantment Software

Real-Time Contxt Engine


Wearables Home Page

Enchantment is a software infrastructure that supports the development of distributed applications. Enchantment started off as a context-aware window manager that Ed Keyes outlined in his Enchantment Window Manager Whitepaper, but the window manager project evolved into Anduin. The underlying inter-process communication software developed in parallel with the window manager and has assumed the Enchantment name. Enchantment now consists of two primary systems: Enchantment Whiteboard and Enchantment Signal.

This webpage provides an overview of the enchantment system -- more detail can be found in MIThril 2003: Applications and Architecture paper, published in ISWC 2003

Enchantment Whiteboard

The Enchantment Whiteboard system is an implementation of a whiteboard inter-process communications system suitable for distributed, light-weight embedded applications. Unlike traditional inter-process communications systems (such as RMI, unix/BSD sockets, etc.), which are based on point-to-point communications, the Enchantment Whiteboard is based on a client/server model in which clients post and read structured information on a whiteboard server. This allows any client to exchange information with any other client without the attendant O(n^2) complexity in negotiating direct client-to-client communication; in fact, this is possible without knowing anything at all about the other clients.

This does for inter-process communication what web browsers and web servers do for document publishing - it provides a uniform structure and systematic organization for the exchange of information that does not require synchronous communications.

The Enchantment Whiteboard goes beyond the web server analogy by allowing clients to subscribe to portions of the whiteboard, automatically receiving updates when changes occur. It allows clients to lock a portion of the whiteboard so that only the locking client can post updates. And it even supports symbolic links across servers, allowing whiteboards to transparently refer to other whiteboards across a network. The Enchantment Whiteboard is also lightweight and fast, imposing little overhead on the communications.

The Enchantment Whiteboard is intended to act as a streaming database, capturing the current state of some system (or person, or group) and on modest embedded hardware can support many simultaneous clients distributed across a network and hundreds of updates a second. We have even demonstrated the ability to use the Enchantment Whiteboard with the Signal system for bandwidth-intensive VoIP-style audio communications.


  • The Enchantment Whiteboard source code that builds the whiteboard server and the client API can be found in the enchant_ipc module of the BorgLab CVS repository.
  • Some useful Enchantment Whiteboard applications can be found in the enchant_apps module.
  • The Borglab Wiki has the most up-to-date information on the Enchantment IPC project.
  • The enchant_ipc module's client_ipc.h header file contains documentation on the Enchantment Whiteboard C API.

Enchantment Signal

For higher bandwidth signals, especially those related to the sharing and processing of sensor data for context aware applications, we developed the Enchantment Signal system. The Signal system is intended to facilitate the efficient distribution and processing of digital signals in a network-transparent manner. The Signal system is based on point-to-point communications between clients, with signal “handles” being posted on Whiteboards to facilitate discovery and connection. In the spirit of Whiteboard interactions, the Signal API abstracts away any need for signal produces to know who, how many, or even if, there are any connected signal consumers.

Any type of structured numeric data can be encoded as a signal. Signal producers may be sensors, feature extractors, filters, or regression systems, and may produce other signals in turn. A typical organization is a sensor signal producer talking to a feature extraction signal consumer, which in turn produces a feature signal that is consumed by one or more modeling or regression systems.

The results of modeling or regression can themselves be signals, or (more typically) posted on a whiteboard for other clients to use.


  • The Enchantment Signal code, which also requires the enchant_ipc module, is located in the signalcore module of the CVS repository. This code makes the signal shared object that all Enchantment Signal applications dynamically link against. It also makes several basic signal applications that create signals from files, log signals to files, visualize signals, etc...
  • The signaldev CVS module contains the source for Enchantment Signal "device" applications that produce signals from peripherals like accelerometers, the Hoarder, IR tag readers, audio devices, etc...
  • The signals.h header file in the enchant_ipc module documents the Enchantment Signal C API. 
  • The Signal.hpp and SignalGen.hpp header files in the signalcore module define C++ wrapper objects of the C functionality.