You are not logged in. Please login or register.
chumbysphere forum → The Future → Solution: Widget authors hosting their own widgets?
Hi there.
I am a Chumby Fan and also a widget author. I've been reading bits and lines here and there on this foum about solutions for reviving the Chumby. I couldn't find anything about Author hosting their Widgets. The idea has probably been discuss but still, I'm asking:
- Why couldn't we, Widget authors, host our own widget? Wouldn't that free up some air?
The main problem with this option is, what happens if the widget author decides to stop hosting the widget? If there's some sort of process in place that lets Blue Octy take over the hosting then it might not be too bad (though once again increasing the load and cost on Blue Octy), but what if the widget author doesn't want to bother with that process, or if something happens financially/etc and the author's server is shut down by the hosting provider?
I think the peer-to-peer hosting option, if Duane can cook up a workable implementation of it, would be the best alternative to your suggestion. This way the author can still participate in hosting, the hosting load on the author's server will likely be much smaller, and if the author's server is shut down for any reason, the other p2p nodes automatically pick up the slack and nothing's lost or broken.
I say Too bad for the author!! LOLLL... seriously. The Chumby jumps to the next widget.
This would also clean up the library from all those wierd widgets that were put there for .. i'm pretty sure... just testing.
I can easily see a certain kind of "market place" that centralises the submited widgets and a way for the authors to have a one step "Add to your Chumby" button on their webpages.
Or let's all link together our Dropbox account... LOLLLLL
I think the "what if the author's site goes down" issue is irrelevant. Big whoop - all functional websites are generally "always-on" anyway, and if the site goes down (or the links change and "rot" 404s to devices) then clearly that widget should've been dead anyway. Lots of widgets rely on external data already, and it's always been my impression that those widgets were hosted by the companies themselves anyway.
At this point I think it's safe to say we can throw out the entire rulebook and start completely over, or at least open the door to significant changes like this. I was kinda moved by the "Save Chumby" video from chumby.com - just glancing over at my dead Chumby One and decided to poke my head in to see if anything's changed. It just doesn't seem right that the whole device needs to be shut-down and made pointless just because it costs too much to host and maintain. Why not spread the load across the interested parties?
Peer-to-peer hosting is an absolute crapshoot, *but* does seem plausible... there's tons of unused storage on most Chumby devices. I know my C1 has a 2gb MicroSD card, mostly unused - I loaded some music directly onto it via SCP in the past and it's still there today. But like Spotify, P2P hosting can be problematic and intrusive if the user's not expecting it. I definitely think the self-hosted widgets plan would be the best way to go - as it should have been done from the start, IMO...
If at all possible, please let us host our widgets. Only serious Chumby devs are going to even consider this option. And it would be for the love of the device. You don't get better developer love than that.
I still have Chumbyland running and waiting. I would be willing to host my own widget and my server(s) have been active for years upon years. I think most if not all developers who opted for this option needed to pull out, then they would be willing to at least give HQ the heads up.
If you're not open to alternative financial resources like donations, etc. then please give us die-hard devs an option to keep our widgets alive.
Oh, and many, many, many thanks for what you've done so far. 
Best,
CB
Thanks guys - this is good feedback.
Why can't we do like google play or all other places and pay a dollar a piece or so for our widgits! Right now I would be willing to pay for the ones I want. I live on a fixed income and I still pay for apps. I know chumby has always kept a free spirit but why can't the users help out?
The difference between Chumby and an Android device (or iPhone or any similar smartphone today) is that Android/etc apps are downloaded from the app store and served on your device, whereas Chumby widgets are stored on the server and reloaded every time your Chumby boots up. This incurs recurring bandwidth costs that Blue Octy can't afford (since Blue Octy's budget is more or less Duane's wallet).
I think the original idea behind this was to allow widget authors to maintain maximum control over their widgets, giving them the ability to revoke widgets at will and provide updates as well. Unfortunately this functionality has now crippled the Chumby due to its network requirements 
Why cant the Chumby Central send down widgets with expiration certificates or some mechanism like that. Then the local chumby could cache the widgets until expiration or until the certificate is revoked
That may be possible, and in fact I just made some suggestions to Duane earlier today; however, this would require a rewrite of the Chumby software (and possibly the firmware) to handle such a thing.
Duane is obviously dedicated to Chumby, as he's paying for what we still have (stub server, forums, and wiki mostly) out of pocket. Unfortunately, his free time to actually make changes to the infrastructure (including the Chumby code) is limited, as he has a day job to pay the bills -- including Chumby's -- and probably would like to spend time with his family too 
It's not that this (or something) won't get done... it'll just take some time. Patience is a virtue!
Well, yes, it probably would need to be implemented in firmware to be secure, but really, what it is protecting is NOT redownloading widgets, so a software change in the loader is probably all that is needed. I agree, it is a slow process, certificate handling, and would take a bit to write.
My last job was certificate web code. It is a pain to debug. I got grey hair over it
Until 2009, I owned and ran an ISP in my basement, 2700 customers, all web sites for the towns in NH (Well, quite a few). If I still had it, I'd be glad to host everything for nothing, but alas, it is all gone (Turned into money in my pocket)!
I have some semblance of an idea to make this work:
The widget authors have two options with their widgets:
A: Get them hosted by Blue Octy, but they lose control of the thing, so Duane could avoid such a conundrum in the future and give people the option of buying a USB stick so they could have widgets if the servers go down for good.
B: The widgets get hosted by the creator, who of course has complete control over their product. This also has the benefit of saving Duane hosting costs.
Any Chumby developers get emailed about this. You can do it for free, if there are less than 2,000 people (And more if you make multiple accounts) at http://mailchimp.com/.
The biggest issue with the downloading of widgets into the device on a persistent basis is:
1) Chumby Classic, which has no meaningful amount of storage (the only persistent writeable storage, /psp, is about 2MB).
2) Non-chumby devices (TVs, Android, etc)
In the first case, we could suggest/require that the user run with a USB dongle at all times to provide the storage space. I don't know of a solution for the second case - the Android client is really just a WebView and we could hope that the device is performing at least some caching. The TV case is more problematic - they're typically running a specialize variant of Flash Lite that's a bit less complex than the one in Chumby and may not include any caching at all.
The current post-Chumby Control Panel *does* attempt to cache the widgets for a few weeks at a time. In the case of the CC, what I do is attempt to store them in /tmp, but set an upper limit of 3MB total for the widget cache. For most channels, this works pretty well, but certain large widgets (Screen Clean, for example) and very large channels will blow this strategy.
The second issue is that when the widget is executed out of local storage, it ends up in a different type of security sandbox, and it turns out that Flash's local storage mechanism ("SharedObject") doesn't work properly. A number of widgets use this to try to store certain data across executions in order to reduce network traffic - for instance the NOAA widget will attempt to store the weather station code for the user-supplied zipcode. Some of the RSS widgets try to store "last article read" and/or scroll positions.
chumbysphere forum → The Future → Solution: Widget authors hosting their own widgets?
Powered by PunBB, supported by Informer Technologies, Inc.
