Here are a few ideas about organizing state in the new system.
In the current Room OS, there are two levels of state. There's the database and then on top of this the "hypercard-y" bits of state on objects (Variables, Attachments, ...).
In our next system, it seems like we want all state to live on objects. Whether or not there is a database that makes this work is behind the abstraction boundary. Such a database would not be exposed by the system.
In Hypercard, all state (properties) and behavior (scripts) are "attached to" or "live on" an on-screen object (card, button, text field, etc). In Apparatus, all state (attribute values) and behavior (attribute expressions) live on a shape. In both, you can pull up an inspector to see or edit any of this state.
I was inspired by Bret mentioning on Friday how he wants to be able to laser a camera and then see what the camera is seeing. What the camera sees is virtual state, so it needs to live on an object. And what better object for it to live on than the physical camera itself.
Here is a mockup of inspecting a webcam:
Here's what inspecting the lion in the Serengeti might show you:
You see all the virtual state as a list of properties. Values are shown as their visualization (as in previous email). You can use (reference) any of these values within expressions, as in Apparatus/DDV. Or you can reference objects in scripts and change their properties when events happen, as in Hypercard/Smalltalk.
I feel like this simple model can take us very far. Just inspect a few objects--use as many inspector boards as you want, we've got all this space!--then hook the data together like in Apparatus or Hypercard.
The hooking together is easy. Generally Hypercard scripts and Apparatus expressions are short. You get rich behavior by setting up rich relationships between objects.
Virtual state encompasses:
- In data: image the camera sees, what keys are pressed down on the keyboard, the accelerometer data on the wiimote.
- Out data: brightness level of the LED, image the screen should show, image the printer should print, angle the servo should go to.
- Variables: angle the frog's eyes should be looking at, mole game time remaining, laser socks "health level".
- Attachments: lion's roar sound, mole image, Whole Earth Catalog's page images. (Attachments are essentially constant variables.)
- Behavior definitions: expressions that evaluate, scripts that run.
All of this state would be accessible and editable in a uniform manner by inspecting the object it lives on.