Actually, that's *not* the way you want to do that.

The system is being designed so that you create multiple "profiles" - a collection of configured widgets.  A chumby is configured to show a particular profile - multiple chumbys configured to the same profile will show the same data.  You can replace your chumby, or change its profile, without losing any configuration.

That means you *don't* want to store any kind of configuration information on the chumby itself.  If you provide some sort of configuration on the device, that configuration should be uploaded to the server for storage.  There is an API for doing this, and a couple of our widgets do this.

The only things that should be stored on the device are things that only are relevant to that individual piece of hardware - brightness settings, alarm time, etc.

At the moment, SharedObject is not functional in order to discourage storage on the device - if/when it is, it will very likely only store that data to RAM, meaning that it will lose that information when power cycled.

We actually have an (as yet unpublished) weather widget that shows conditions and forecasts for US locations based on zipcode.

The reason for disabling the Flash save feature is because people will expect to save to the device itself (which has an almost full chip as it is), and not to an additional NAND chip. As for PNG and GIF, I'm not sure why they don't exist yet. It's possible they had the choice of either licensing the PNG/GIF code at a greater cost, or buying Flash Lite without it and they chose the latter (knowing that they could use GPL'd libraries later to add PNG and GiF support, or write their own modules).

As of right now, everything's alpha (not even beta; there are plenty more features on the way). Expect limitations for the time being. Or, if you're like most of us and don't have a Chumby, sit back and relax, and enjoy the developer ripping each other's hair out over problems.

d'oh.. I meant LGPL.. it's been a long morning.. and I didn't know about the yucky Adobe license.. sucks. Well, there's always BSD/Public Domain to look at, and I'm sure there are PD/BSD libraries for PNG, though I'm not so sure about GIF (as it used to be held hostage by the Unicrumb patent).

It's time to browse the interwebs.. we'll see what we can't come up with in the way of decoding libraries to help you guys out.

EDIT: Hmm, libPNG uses the same license as zlib, and it's quite literally one of the most liberal software licenses ever written
(    * Software is used on 'as-is' basis. Authors are not liable for any damages arising from its use.
    * The distribution of a modified version of the software is subject to the following restrictions:
         1. You must not claim that you wrote the original software,
         2. Altered source versions must not be misrepresented as being the original software, and
         3. The license notice must not be removed.)

If you could get it to build on ARM, you'd be home free, and it shouldn't be that difficult as it's written in C and is already cross platform. Libmng (motion PNGs) is also licensed under zlib. Now if we can find a gif decoder under zlib...

On the subject of security, is it possible for a Flash app running on the Chumby to use TCP to access other devices on the LAN and upload what it finds to some arbitrary site on the Internet? If this were possible, some jerk could snoop through shared drives and upload interesting files it found.

Yeah, I know...I need to go learn about Flash development. Talk about something I never imagined I would ever do. Chumby may revolutionize Flash development. Adobe may love you guys for this.

FL2.1 does support XMLSocket.  However, local SWFs do not obey any policy files.  Big security problem.

When you say you don't run the widgets as a Local file but from the chumby.com domain... does that mean We won't be able just upload a widget through USB and run it without any internet connectivity?

I don’t agree with some of the security concerns you’ve stated about read/write access. Every time someone downloads anything from the internet there is that little risk of a virus or a Trojan. Every beta app, Any konfabulator widget, Mac Widgets and so forth has the potential of being something that can kill your machine.

I’m a network admin and ever time someone installs a Trojan or spyware on their PC, I don’t go cursing Microsoft because the Idiot wanted to download a Poker Game from a site called WeWillHackYoStuff.com. If you install something, you’re pretty much trusting the application and granting it permission to do what you hope it to do. Why limit innovation just because some people aren’t careful in using their gear.

A few others and I are pretty excited about the chumby and coming up with ideas of what we can develop for the little sucker. You might just see it as a fancy alarm clock, But it can be soo much more then that. Limiting some functionality just because you’re worried that an idiot will install a bad widget and break his chumby in the process, just doesn’t sound right.

There is a lot of things that people can do if given the ability to write to the USB drive from a flash widget.

could you not put things like zip codes on a server? like if you paid for a widget, some of that cost goes towards paying for the server? cos we've got account now, so why not store any info needed on there, and then when chumby needs it, it identifies itself to the server, and gets the required information. granted, it may slow things down, but when theres not that much storage, it might be better to run it on a server.

I was wondering if this situation has changed at all.

I understand that configuration data should be saved to the server. However, there are scenarios where a widget may want to remember something between times when it is run within Chumby which aren't important to remember overall.

For example, if you have a slideshow which plays back hundreds of images, it won't be able to play them all within the standard 30 second time allotment within the chumby. You would want the widget to be able to save the index of the last image it displayed and start from there the next time it's instantiated. Is there currently a way to handle this scenario with the Chumby?

Yes, this is old information - the production chumby supports what Adobe calls "Mobile Shared Objects", which are a subset of Local Shared Objects.  The primary difference is that the data can't be shared across domains, but they're quite sufficient to save information across instances of the same movie.

On the chumby, Mobile Shared Objects are stored in RAM, and thus do not survive power cycles.

My advice is that you have the widget store the high score information, with a timestamp, in a Mobile Shared Object, then use the Date object in your widget to determine if you need to reload it.