You are not logged in. Please login or register.
chumbysphere forum → Flash/Widget → Default file structure / tree
Are there/will there be any default folders MS style for images/sounds/movies/etc.? Something like My Photos for example?
I'd like to allow the user to have his own collection of photos, and have my applet automaticall grab photos from within that folder. True, I can prompt the user for the location of the photos, but it would be nice if there was a default location for users (gradmothers, for example) who do not wish/know how to create their own folders.
The chumby is not designed to have anything significant stored on it. It only has 64MB of NAND Flash and that's used almost exclusively for firmware. The only data actually stored on the device is settings related to that particular piece of hardware - brightness, volume, timezone, alarm time, etc.
The system is designed to store any persistent data on the server. Even then, the amount of data per widget that can be stored is relatively small, typically userIDs for other sites, or zipcodes and such In general the data that the chumby displays comes from around the web.
For instance, we don't have an image server - we leverage the pre-existing sites such as Flickr to host them and we play them back. Most people have their images there, or some similar sites, already - why ask them to upload them again to *another* website.
A side effect of putting all of the settings and content on the web is that you can have multiple chumbys displaying the same data, and that nothing is lost should a chumby fail.
Several people have insisted that the chumby *needs* local storage, like a personal computer. However, putting a substantial amount of storage is cost-prohibitive - no one will buy a chumby priced above a certain threshold.
Oh, I agree with you, and I wasn't really expecting to host the photos on the Chumby itself, I'm aware of the amount and tpye of memory it has. What I was actually asking is whether the Chumby will have a tool of sorts to "pre-config" a user's USB drive with default folders, kinda like the wireless companies do with the memory cards that come with the phone.
It's not a big deal, and it's true that most people already have their ima(g)es on the web, but some might just not, or they will want to use the Chumby as an( )eBook reader that plays MP3z in the background while they read. Having the option to pre-configure a drive to match the default pathes the Chumby uses will be a very good thing.
Catch my drift?
(Fixed some spelling mistakes)
No structure has been defined for the layout of a USB drive device.
There is another thread discussing security issues regarding arbitrary access to local file systems.
If we are to give any sort of access, it would have to be extermely structured in order to conform to security best practices.
Yeah, I read that thread, but what I'm talking about is not running any executables, just default locations for media files. And if you guys ar ethe ones who write the tool that will help the user to set his folder structure properly, there's not security issue what so ever.
would there be support for samba shares? or even ftp? cos then people that wanted mp3s and stuff to play, could stream them off of a network server, or another computer.
usb support is deffo a good feature, because most people own at least one usb key, so putting mp3s and pictures on it would be easy.
Seems to me like the only thing the Chumby firmware needs to do is load Flash apps. Then Flash apps will do the rest. So in this case it sounds like you're wondering if the Chumby-provided media player app will know where to look on a USB drive to find local media (in addition to knowing how to go find network media). Sounds like that's a pretty easy thing for the Chumby folks to code in, should they want their media player to do that, anyway.
If they don't, you write your own media player (or hack an existing one) and you create your own local media "standard" to do the same thing. Personally, I don't care as much about a standard as I do the ability to configure your own place to look. There are a lot of folks out there that already carry USB keys that are setup with viewing software for Mac or Windows and their library of pictures or MP3s so they can show off their kids easily or play their music on any computer they happen to be sitting at. While they may not carry a Flash app on there, too (though I suppose it would be nice if they could and Chumby could be configured to also load local Flash apps), more likely they're just going to want to get a Flash media player that can be configured to hit the local media, too.
--Donnie
Well, there are still some security issues with this that we'd have to resolve.
If we give a widget that came in from the network free access to the USB device, there's nothing stopping someone from reading files from the device and uploading them to some random site on the net. That's a security hole we simply can't allow.
FlashLite *does* have the notion of being able to download and store media assets, which comes from its history as a platform for phones - they needed to support the downloading of ringtones, wallpapers, etc.
However, this is not free-form - the asset is identified by an arbitrary category (ie "ringtone", "wallpaper"), not a path, so the Flash developer really has no idea or control over where that asset went or what happens to it after it's downloaded. Presumably the underlying OS takes over from that point.
I guess I'm interested in the opinions of everyone on the notion of "formatting" a USB mass storage device that's inserted into a chumby. Is this something we should do? What about non-passive devices that already have an existing file structure, such as iPods? What if our structure directly conflicts with the normal operation of the device?
How much management of the storage should be presented to the chumby user? Is there now a full file browser? How do we handle full media, locked files, permissions, etc? Is this *really* something we want somebody to have to deal with to use a chumby? Isn't this all just trying to turn this into a computer?
Well, there are still some security issues with this that we'd have to resolve.
If we give a widget that came in from the network free access to the USB device, there's nothing stopping someone from reading files from the device and uploading them to some random site on the net. That's a security hole we simply can't allow.
I'm still getting up to speed on the "philosophy" guiding Chumby (and let's not split hairs...it *is* a philosophy), so bear with me a bit. From what I had read, I *thought* people were going to be able to run Flash from places *other* than just your server. The more I think about it, maybe that was a "maybe" you'd let that happen.
At any rate, *I* would prefer to see Chumby easily able to load Flash from non-Chumby servers. Not because I don't like what you do or trust you (Chumby-corporate), but because it's just a more useful device to me if we can all "do our own thing" a bit with it. Now, I fully understand the open nature of this beast will let me go hacking on it to *make* it do what I want, but that's not what I'm after. Just the ability to get Flash from anywhere I want. I think that will build communities a lot better that only allowing Flash from chumby.com. Maybe that's the intention, I'm just being thorough with what *I* want right now.
Now, why couldn't you allow a chumby to upload to an accessible upload site? Sounds like something people might want to me. It's up to the sites on the net to be secure from rogue uploads. I must be missing something here.
Past that, I'd really like my alarm clock to be able to play the music *I* want to hear, and it may be that I have that music on a USB key. It may be that I want to use Chumby in some place that doesn't have wifi and still want the alarm clock to work like it works when it *is* connected.
(And a feature request I'd like is the ability for the Alarm Clock widget to play a background track in a looping manner as it then becomes a "noise machine" and can interrupt the "noise" with alarms.)
I guess I'm interested in the opinions of everyone on the notion of "formatting" a USB mass storage device that's inserted into a chumby. Is this something we should do? What about non-passive devices that already have an existing file structure, such as iPods? What if our structure directly conflicts with the normal operation of the device?
I think having an option to format is fine, but being able to read (and potentially write) a FAT formatted USB filesystem would be a very nice feature. But I can't see a good reason why you'd really have to format to something proprietary.
How much management of the storage should be presented to the chumby user?
However much they *need* for the Chumby to be successful as a product. Sounds like the goals you guys have for Chumby don't include any need for this. That said, if people out there want it, they'll create a file manager widget of their own (such as it can be created due to what appear to be some pretty severe Flashlite limitations).
Is there now a full file browser? How do we handle full media, locked files, permissions, etc? Is this *really* something we want somebody to have to deal with to use a chumby?
Have to? No. Be able to? Yes.
Isn't this all just trying to turn this into a computer?
Sure. But look at all the other threads with feature requests like this. It's just another one, and you have to figure out where each one falls on the ever-forming chumby philosophy.
Personally, I think you'll have the greatest acceptance of the device if it does the Alarm Clock thing insanely well, has panache (I think it already does), and is open enough to lightly "hack" even for folks that aren't hard core (which is where I think the openness to getting widgets from anywhere comes in).
--Donnie
Seems to me like the only thing the Chumby firmware needs to do is load Flash apps. Then Flash apps will do the rest. So in this case it sounds like you're wondering if the Chumby-provided media player app will know where to look on a USB drive to find local media (in addition to knowing how to go find network media).
No man, you missunderstood me. This forum is for the Flash Development of the Cumby, not just random inquiries about what it can, or can't do. All the questions/requests in these forums come from people like me who have an idea for an applet/widget, and are trying to find out whether it is possible to do or not, and what are the tools/features currently in place to help them make that idea come to life in the easiest, quickest, way possible.
If they don't, you write your own media player (or hack an existing one) and you create your own local media "standard" to do the same thing. Personally, I don't care as much about a standard as I do the ability to configure your own place to look. There are a lot of folks out there that already carry USB keys that are setup with viewing software for Mac or Windows and their library of pictures or MP3s so they can show off their kids easily or play their music on any computer they happen to be sitting at. While they may not carry a Flash app on there, too (though I suppose it would be nice if they could and Chumby could be configured to also load local Flash apps), more likely they're just going to want to get a Flash media player that can be configured to hit the local media, too.
My question about the default folder structure and such is designed to help figure out whether there should be a tool (formatter, as Duane called it) that will create default folders on a USB drive inserted by the user.
Writing your own MP3 player is quite an easy task, and the issue of writing one that can pull files from a USB drive is not the issue here. The issue here as *where* will those files be stored. Should there be a "default" location where the player can access *first* and play the files it finds there. Obviously, such (and any) MP3 player applet will allow the user to set the location of his music files to wherever he wants, be it on a remote location (ftp, remote computer on the network), or locally (on a USB drive, Memory stick, etc.)
Our only dilema here is should there be such a default place or not.
I'm still getting up to speed on the "philosophy" guiding Chumby (and let's not split hairs...it *is* a philosophy), so bear with me a bit. From what I had read, I *thought* people were going to be able to run Flash from places *other* than just your server. The more I think about it, maybe that was a "maybe" you'd let that happen.
At any rate, *I* would prefer to see Chumby easily able to load Flash from non-Chumby servers. Not because I don't like what you do or trust you (Chumby-corporate), but because it's just a more useful device to me if we can all "do our own thing" a bit with it. Now, I fully understand the open nature of this beast will let me go hacking on it to *make* it do what I want, but that's not what I'm after. Just the ability to get Flash from anywhere I want. I think that will build communities a lot better that only allowing Flash from chumby.com. Maybe that's the intention, I'm just being thorough with what *I* want right now.
Now, why couldn't you allow a chumby to upload to an accessible upload site? Sounds like something people might want to me. It's up to the sites on the net to be secure from rogue uploads. I must be missing something here.
OK, this discussion is about the security aspect of read/write access to local storage in concert with the ability to also have access to the network.
The chumby *already* allows users to access and use movies and data from remote servers that have granted permission through the "crossdomain.xml" file. Several of our widgets pull RSS feeds, and several download images (could just as easily be movies) from non-chumby servers. You can even upload information with POST - we have an existing widget that does this.
However, if you grant that *and* read access to the USB device, you've opened up a security hole that allows a malicious widget to pull personal data from the USB device and upload it to a server.
Imagine what would happen if the normal desktop Flash plugin allowed this - that by simply viewing an ad on a web page, all your private files could be uploaded to some server somewhere. Macromedia has wisely prohibited that. So should we - in fact we do so because we're using their security code. It's actually quite a pain in the ass to remove it.
So it's not about servers getting rogue uploads - it's about allowing access to the information being uploaded in the first place. The assumption is that the servers are getting this information because someone set them up that way, in order to collect this potentionally stolen information.
Again - this is Network Security 101, Day One, Lesson One. This is so fundamental that it's generally never up for debate for anyone that knows or cares anything at all about security.
As I mentioned before this issue has been the cause of pretty much all of Microsoft's vulnerabilities that haven't been due to bugs like buffer overflows.
Duane wrote:Well, there are still some security issues with this that we'd have to resolve.
If we give a widget that came in from the network free access to the USB device, there's nothing stopping someone from reading files from the device and uploading them to some random site on the net. That's a security hole we simply can't allow.
I'm still getting up to speed on the "philosophy" guiding Chumby (and let's not split hairs...it *is* a philosophy), so bear with me a bit. From what I had read, I *thought* people were going to be able to run Flash from places *other* than just your server. The more I think about it, maybe that was a "maybe" you'd let that happen.
At any rate, *I* would prefer to see Chumby easily able to load Flash from non-Chumby servers. Not because I don't like what you do or trust you (Chumby-corporate), but because it's just a more useful device to me if we can all "do our own thing" a bit with it. Now, I fully understand the open nature of this beast will let me go hacking on it to *make* it do what I want, but that's not what I'm after. Just the ability to get Flash from anywhere I want. I think that will build communities a lot better that only allowing Flash from chumby.com. Maybe that's the intention, I'm just being thorough with what *I* want right now.
You will most likely be able to run your own Flash applets locally (local network, USB drive). I know you'll be able to run them from a USB drive, not sure about the local network or the web, Duane can answer that.
Even if such an option (running a Flash file from a site other than Chumby) is not available, you could always write a blank Flash movie that loads another one from a remote website, as the devflash pages state, so don't worry about that. Since you will be able to do that, I'm pretty sure they'll just let you run the movies straight from another page, and save you the hassle of writing such a "loader".
Now, why couldn't you allow a chumby to upload to an accessible upload site? Sounds like something people might want to me. It's up to the sites on the net to be secure from rogue uploads. I must be missing something here.
It's not a question of allowing uploads to a remote location, and the issue of allowing a flash applet that comes from Chumby, or a remote website, access to your local files/network in order to upload those files. Giving the remote applet that capability means theres no way of stopping it from accessing other local files you might have, that you didn't intend it to upload.
Past that, I'd really like my alarm clock to be able to play the music *I* want to hear, and it may be that I have that music on a USB key. It may be that I want to use Chumby in some place that doesn't have wifi and still want the alarm clock to work like it works when it *is* connected.
(And a feature request I'd like is the ability for the Alarm Clock widget to play a background track in a looping manner as it then becomes a "noise machine" and can interrupt the "noise" with alarms.)
Again, the issue of this or that feature of an exisitng applet is not relevant here. You can always write your own alarm clock that does anything you want. The question here (still) is what to allow that applet to do, and where.
Duane wrote:I guess I'm interested in the opinions of everyone on the notion of "formatting" a USB mass storage device that's inserted into a chumby. Is this something we should do? What about non-passive devices that already have an existing file structure, such as iPods? What if our structure directly conflicts with the normal operation of the device?
I think having an option to format is fine, but being able to read (and potentially write) a FAT formatted USB filesystem would be a very nice feature. But I can't see a good reason why you'd really have to format to something proprietary.
As I wrote in my previous post, the term "format" was used by Duane to set the structure of of files on the drive, not to actually format and change the file system of the drive.
Ah, gotcha. Sorry, missed that potential flaw.
That is quite a can of worms, obviously. It's also part of the reason why MS has their "trusted" mechanism for device drivers and such. Perhaps there needs to be a certificate setup for Flash apps, too. Choose to run an untrusted one and you could be warned about potential security problems (and you could config the chumby to not allow connected media access from untrusted apps, etc). Otherwise trusted apps get full access.
Then you have to setup a facility for securing applets, which could obviously be a huge pita. But there may be other benefits of that mechanism anyway. You could also allow users to download certificates from third parties if they trust that third party's content, too.
At the core this is really no different than any other downloaded and installed application on any operating system, though. Well, except that it obviously happens in a much more transparent manner, much like a user simply loading a web page on a desktop machine. I see where you have to be careful here, but I'm not sure it's a *huge* deal.
--Donnie
If we give a widget that came in from the network free access to the USB device, there's nothing stopping someone from reading files from the device and uploading them to some random site on the net. That's a security hole we simply can't allow.
FlashLite *does* have the notion of being able to download and store media assets, which comes from its history as a platform for phones - they needed to support the downloading of ringtones, wallpapers, etc.
However, this is not free-form - the asset is identified by an arbitrary category (ie "ringtone", "wallpaper"), not a path, so the Flash developer really has no idea or control over where that asset went or what happens to it after it's downloaded. Presumably the underlying OS takes over from that point.
The security issues are obvious, but not having access to the USB drive will limit the developement of widget quite alot.
Having the alternative of pre-structured folders (be it virtual, or physical) will solve both issues. It will allow developers a place where they can pull files from, and yet limit them from other places they shouldn't get into. Just like on an FTP server, you hold everything in a secure folder, that not even "root" has access to (from the ftp client). The "formatter" that Chumby will provide will prompt the user when he inserts a USB drive to configure his drive to work with the Chumby.
It'll ask the user whether he wants to set the default locations for the folders, or use existing ones on the drive, stating clearly that those folders will be accessible from remote location as well.
This will solve all of the other issues you have with "file management"; You have pre-defined folders for music/photos/movies/whatnot, and then you can let the user create a "public" folder for him to put other stuff he might want locally that you and I can think of at the moment. If you make it crystal clear that any folders defined in the Chumby are open to the world, you'll be fine.
If you wish to go a step further, you can create two "security zones" on the drive, and let the user set which folder should be open to the world.
I don't think you should create a file manager for chumby, style Window Explorer, but it *should* have some file management capabilities, such as read/write permissions and private/public permissions.
Regarding turning this into a computer; Your whole mantra for this thing from day one was "Openess". Let the people hack it into anything they want. The hackers out there will ALWAYS try and turn a piece of hardware into a computer. Look at all the routers running linux, or the PSP. I can't think of a nicer thing to have in my hand then a cool, 3.5" LCD PC that hooks up to the web via WiFi, and lets me do all my cool shit on the go, with access and capabilities as close as possible to that of my laptop.
I understnad your goal of trying to minimize those features because of the novice part of your audience (grandma's, kids, etc.), but if you make it "limited" and secured by default, and add an option deep, *deep*, inside the security pages, that opens it up to be proned with a 5ton hammer, if one chooses to, you'll make the Chumby the best piece of hardware on the market.
yeah, you should make chumby a bit like azureus, whereby on the first boot, it asks you whether you are a beginner, intermediate, or advanced, and then displays settings and such accordingly.
My 2 cents here...if you look at the corporate web page the first impression is that the target market is teenage girls who want a cute alarm clock with web content. On the other hand, it has hackable open source hardware/software. A totally different source of appeal...and that is the market that is prevalent (over-represented) in this forum.
These two markets are so at odds with one another it's going to be a huge balancing act to cater for both and keep both happy. I'm not 100% sure...but where does the money lie for chumby corporate? I think with the bedazzling tweens, personally. Not only through the unit but future widget subscription services. (Chumbians - have I got the gist right here?). I think this market is what is enabling the company to have the open source philosophy discussed above.
So, I think in our discussions we are going to have to keep both in mind - as chumby corp. has to. We can hack to our heart's content but for financial survival, and for you to actually get a chumby in your hot little hands in the first place, the company needs to acknowledge the average tech. consumer...and that is why certain features exist in the device. They may limit you, but it enables the other users. We are an interdependent social network....we gotta co-exist...
You are right, Angela, to a cretain extent. We are totally *for* having the Chumby simple to use and appeal to youngsters. I know they represent the biggest market for such a gadget, and no one is really trying to make things harder on them. Quite the opposite actually. The whole reason I started this thread was to find out whether the chumby will have a default location where media will be stored, so that I, as the software developer, wont have to force it on the user. The user will be able to just plug in his USB drive, and listen to his favorite songs, or watch the movies how just got from his friends.
I think the the debate here ahouldn't be on whether or not "file management" (or any other feature for that matter) should be imlamented, but *how*.
As chedabob suggested, prompting the user for the level of "sophistication" who prefers is a good option to solve that. put in all the features advanced users will want, but shield the novice user from it until he is ready for them.
Personally, I think there shouldn't be any prompt when a user turns his Chumby on for the first time. The Chumby should come pre-configured in a certain way, with all the limitations turned on, and then have a seprate section in the Control Panel where users can tweak it to their likings. Just like Firefox, Shareaza, and any other open-soure project functions.
There's no reason to confuse a user who barely understands how WiFi works with useless prompts. An experienced user will know how to go into the Control Panel and access the advanced configuration section.
Here's the way I think this is probably going to work:
You'll be able to create widgets, put them on a USB storage device, and have them run in the normal rotation of widgets configured from the network. Those local widgets will have the ability to access local file systems, and even upload stuff to the network. However, if they load movies from remote locations, *those* movies will be sandboxed, and will not be able to access local content.
If you want your friends to have those local widgets, you'll have to email them out-of-band, and they can put them on *their* USB keys, and have all the powers. However, if you upload them to the network, and download them as part of the normal network operations, they'll lose the ability to access the local system.
This turns out to be *exactly* the same rules that the desktop Flash standalone player application and the Flash browser plugin follow. The assumption is that if the movie is on your machine, then you are implicitly taking the risk that it might compromise your system, but if the movie comes from the internet, then it runs in the security sandbox.
This allows the hackers their fun without compromising the other users.
I'm not sure we're interested in introducing special configuration modes into the system, and we're not particularly interested in distributing widgets that *require* anything not in the base unit - otherwise nobody will be able to make any sense of what they can run and what they can't.
That seems completely reasonable. It follows the same paradigm as "installing" an application versus "clicking on" an application in a browser (on a desktop machine). I want whatever I click from the network to be sandboxed, but I expect anything I download and "install" to have full priveleges.
So would that mean an alarm clock widget I run from chumby.com will *not* be able to play an MP3 as my alarm sound from my local disk, but it will play an MP3 I have it grab from the network, correct?
Will any, or all, of the widgets on chumby.com be downloadable so you could put them on local disk and then configure them to use items off the local disk? I ask because it would be nice to be able to use Chumby as an alarm clock in places where I'm completely disconnected. It is rare, but it does happen. 
--Donnie
Sounds reasonable - I'll look into it.
This makes perfect sense, and is totally acceptable. It follows the rules of the existing Flash environment, which is even better because it simplifies the developers' need to learn how the Chumby environment works.
The only issue left unclear is will the Flash Lite version installed on Chumby allow us full access to the file system, like Flash does?
It is going to very important that users will be able to save any and all widgets installed on the Chumby locally, so that they can be run locally if one chooses to. That way, people like Donnie can have their alarm clock work even when not connected to the web, without requiring them to have two separate versions of the same widget.
It is going to very important that users will be able to save any and all widgets installed on the Chumby locally, so that they can be run locally if one chooses to.
Hmmm, there may be some licensing concerns regarding that, particularly with "premium" widgets where the creator doesn't want the widget run outside the service. We'll need to see how that issue can be dealt with from a legal standpoint.
And, of course, any widgets that rely on external web media, such as widgets using RSS feeds, make no sense to run in a no-network environment.
Frankly, I think the number of chumbys with USB dongles, and hence the ability to save content, will be extremely small compared the installed base.
It is going to very important that users will be able to save any and all widgets installed on the Chumby locally, so that they can be run locally if one chooses to. That way, people like Donnie can have their alarm clock work even when not connected to the web, without requiring them to have two separate versions of the same widget.
Yeah, seems like being able to pop up a master control panel during a widget that at least has a "save current widget to filesystem" button would be good. Since I'm not one of the lucky few with a prototype (but if anyone wants to sell...) I don't know if you can get to a control panel while in a widget, but it sounds like there is a generic control panel of some sort already. Hopefully the design allows for multitasking at least a little bit...obviously not in the window manager sense, but perhaps in the "stacking" sense.
--Donnie
Frankly, I think the number of chumbys with USB dongles, and hence the ability to save content, will be extremely small compared the installed base.
I hope you're right, because there's a lot more money to be made for you if every teen in America wants this thing. If, however, your market ends up being gearheads, well, you obviously won't sell nearly as many. (And my assumption, obviously, is that us gearheads will definitely be doing things like plugging in USB dongles quite regularly, but Mary-the-16-year-old-babysitter probably won't.)
Hopefully you've got marketing people that can take the best of what Apple has done, add some *more* magic to it, and you have a budget that will let them get that message in front of a LOT of people. Or just cash out now and sell the idea directly to Apple. 
Personally, I think Chumby is exactly the kind of product Apple *should* be doing, especially if they made the brain an iPod that could do what Chumby's hardware and software does (in addition to playing music) and made the rest of the hardware a neat "dock" for the iPod. But since they didn't do that, there's still a market to fill for Chumby, which makes me happier because Apple isn't exactly known for open hardware or software.
--Donnie
Hmmm, there may be some licensing concerns regarding that, particularly with "premium" widgets where the creator doesn't want the widget run outside the service. We'll need to see how that issue can be dealt with from a legal standpoint.
That's true, but I'm sure you can enforce a simple "protected" flag to the premium content files. It wont stop anyone with the right resources to extract it, but at least it wont be "enabled" by default...
And, of course, any widgets that rely on external web media, such as widgets using RSS feeds, make no sense to run in a no-network environment.
That's true, but none the less, one might decide to copy it to a friend instead of forcing him to go and download it himself, or one would want to try and run it on his PC instead. There's no need/sense in putting too many restrictions and separations between widget types. As we all know, anyone with enough will power can hack just about anything.
The way I see it, if it doesn't make the "simple" user's life complicated, it should be included.
Frankly, I think the number of chumbys with USB dongles, and hence the ability to save content, will be extremely small compared the installed base.
I have to disagree with you. I don't know what the difference in price is going to be between the versions, but I don't see any reasons why people will say "Oh, I don't need that USB port, I have no use for it."
*Especially* not when a young girl can hook up her webcam to it and have her pictures/movies uploaded to Flickr, or have a little cool widget running a live feed that can be smudged/distorted with her fingers for hours of fun.
I think you're underestimating the importance and usefulness of the USB port, and unless it's going to be a $50+ difference in price, I doubt anyone will go for the sanse-USB version.
chumbysphere forum → Flash/Widget → Default file structure / tree
Powered by PunBB, supported by Informer Technologies, Inc.
