I like theSharedObjects approach, which is to keep the data on the Chumby, and not to send it back to the Chumby servers. However, mobile shared objects (according to the docs) do not allow different components to share this data; only the 'local' shared objects do.
I cannot think of a killer use for this., except to have the Control Panel publish info that the widgets can use. If the Music player could make available the name of the stream and/or id3 tags of the current song being played, the widgets could do cool things by fetching the album art/or CD/song/band reviews from the web. If the control panel could publish the fact that the alarm was playing, then a widget can be written to play "Wake up, dammit!" (if the alarm was NOT playing, then by the feature of cooperative mode, it can terminate early.)
As a prototype, I recommend making a simple web service on the Chumby itself using httpd which would save stuff to the local chumby and retrieve it. One app can persist its data and retreive it the next cycle.
One example (admittedly of little value) is to take some game that has an online component, like Quake4, and have one widget report all the active servers, allowing the user to sort the servers (game type, number of players, etc) and allow the user to highlight one. This first widget would publish this selected server. A second widget would use the address to print the names of the users on the servers and other specific information from that server. A possible thrid widget could be one that pings the server and reports network latency to it.
The benefit of this is that some people may only want to see the first widget and not install the second or third.
wayn3w