I think the only mechanism allowed by the flash security sandbox for widgets is to use the LoadVars class to send/receive XML to/from a server. This currently requires either a remote server or an installation of lighttpd on the Chumby itself. It would also only support polling for getting updates.

The XML schema and URL format would need to be proposed and developed by the community.

  Clive

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

ChumbyChat is sharing content between multiple users.  How is that working?  Where is that data being stored/retrieved from?

Yeah, I thought that would be the case.
I think Facebook provides limited data storage for Facebook apps.
It would be handy if there was a chumby.com data storage allocation for each widget (other than the configuration options).
Otherwise, the widget developers have to self-fund storage for their apps, with no benefit.
At least Facebook app developers can generate revenue for themselves through advertising.

I wonder if it is within the rules to have a widget that people need to enter a 'code' to use.
Then you can 'sell' codes to people that want to use your widget.
And you could recover costs for providing storage and bandwidth.
Of course, we don't want everything ending up as pay-per-view.