Well, when I said "Flash Player instance", I didn't mean to imply "thread".

The Flash Lite player is essentially a virtual machine - you can create multiple "instances" of the player object within the same process and sharing the same machine address space.  The player instance makes calls intot he implementation layer for allocations of memory, network access, etc.  In the production units, the Control Panel runs in a "master" instance, and has the ability to create, run and destroy "slave" instances, which are the widgets.

There is currently no built-in mechanism for widgets to communicate with each other, and as with the prototypes, the system runs exactly one widget at a time, creating and destroying a new player for each widget.

We consider the chumby device as simply an interchangeable "player", such that any chumby could be replaced with any other chumby with no loss of any of the user's information.  This implies that nothing should be stored on the device itself except for the settings specific to operating that device - network configuration, volume, etc - and anything else that should be persistent should be stored on a server.

One problem with keeping data on the device, assuming you even have anywher to put it, is knowing when it's no longer needed.  Since a user can add and remove widgets from their channels at any time, we're too resource limited to accumulate data on the device that no longer has any purpose.

There is also no current mechanism to run persistent daemons from within Flash.  We have added functionality for the chumby to query POP3 servers from Flash, so it is possible to create a widget that monitors an email account, and we've exposed a couple of other common protocols and services.

For someone that needs more than that, the only solution we provide is the ability to run arbitrary software from a USB dongle.