I love the idea of having Key/Value databases available to camping apps as a standard thing on the platform. They aren't the same thing as a filesystem though, and I don't think we should pretend otherwise. If we don't want to give users filesystem access, that's *fine*, even though I don't see why we shouldn't.
What about this - We make a sister project, ForeverHash, which works just like a normal hash except that when you .new it you have to give it a name, like ForeverHash.new(:people), resulting in people.db existing some place in the filesystem. We could have a campers-toolkit gem which would default to using yaml or marshal or whatever to shove that stuff in a file on close, and read it in on launch. When stuff like TokyoCabinet is available, it'd just magically be faster and awesomer. campers-toolkit could have tons of neat little bonus toys like that. Thing is, Heroku is this big scary thing which is all about performance and big deployments and commercialisation and not at all about learning and hacking and making stupid little games and programs that do your math homework for you (that's why I learnt to write basic!). We already have Heroku. We don't need another abstraction to it. Fake filesystem atop a key/value database would be a fun hack, but it'd go crazy with things like the exotic file locks sqlite uses. I propose this: We settle on the idea that we are in fact an awesome bunch and that camping still has that wonderful educational essence of it's beginnings, and that being loosely connected to _why, we already have some weight with educators. There are computer labs full to the brim with boxes doing nearly nothing in schools all around the place! The internet itself was practically born of excessive computing power at universities needing to find something to do with itself! So I propose we stop eating the little scraps of free stuff the capitalist processes that drive services like heroku and dreamhost produce, and really try and pester the educational systems of the world - see if they'll give us a server and plug it in to some pipes to get this idea going. If we can get a dedicated server somewhere, making secured little app hosting is trivial and fun and super easy to do! Web hosting friends inform me that linuxes have no worries at all with hundreds of thousands of user accounts. That's how tryruby worked way back when - it made a new user account when you entered your first command, ran it, and removed the account if it idled out. That's how try ruby was secure! All we need to do is use the same tools shared webhosts have been using for decades, like unix file permissions and apache or ngynix and passenger and chroot and a user account per user or app, and we have a totally viable way to do this. Passenger will run as many processes as each app needs, and shut them down when nobody is using that app. The ruby processes can run under that user's account, and we can automatically apply permissions to the files as they're uploaded and updated. Then we just short out the system/``/chown type commands in the ruby process with a little bootstrap code added to the rackup and we've got it sorted. The tech here is easy and fun. Getting a server to run it on could be tricky - but we have avenues to explore. We NEED to get a good website up with a blog (I suggest a tumblr, because it doesn't cost anything, can have group committers, all the features we need, and it too is connected to the rich heritage of _why :) Then we can put the callout. Once a plan is formed for the tech and the look of the thing, we can get a blog post up explaining the idea and asking for help, and start mailing it around to universities and schools, asking if they have any extra servers they might donate to the cause. Carnegie Mellon physically hosted art && code. Maybe they'd host us too! // Sidebar: Okay, so yaml and marshal would suck as a backend because it'd go crazy without any obvious reason if the user launched multiple processes, as they may well do if using lighttpd. Still, it doesn't have to be *fast*, so maybe there's some sort of compramise to be had? Marshal the values, and store them in some sort of indexy thing, where we could use filesystem locks to keep from writing over eachother, and garbage collect / compress every now and then. That could work really well, and could be nice pure ruby. Mmmm. Is this crazy? Am I a nut for thinking that a simple multiprocess safe key/value store would actually be really easy to do? I've played with the filesystem as a storage medium a fair bit.. it seems like it should be almost trivial! Maybe I should make this right now! On Sat, Jul 17, 2010 at 11:05 PM, Philippe Monnet <r...@monnet-usa.com>wrote: > I think having a section off of the promo site (and linked from the wiki > too) to showcase simple user-created apps is a great idea as I have not seen > that concept on other sites. > I believe Magnus is building a TryCamping thing too which would be awesome > too. > > I agree with the fact that making it easier for kids/teens to play with > Camping would be fantastic. > I am not sure exactly how to make that happen but you are onto something > with monkey patching part of Ruby too make it safer / easier to do that. > > /!\ warning - stream of consciousness coming up ... > > How about if we used a key-value store (like > CouchDB/MongoDB/TokyoCabinet/...) as an application repository? Here is a > potential scenario assuming a Camping "enthusiast" already has an app > working locally on their box: > 1-Enthusiast chooses to create an app in the "CampingGround" / sandbox > 2-We create a definition for the app as well as a source file based on an > minimal template > 3-We store both in the key-value db > 4-We mount the app and wire the reloader to look for timestamp changes on > the key-value store record > 5-Enthusiast uploads the code - saves commit the code changes to the > key-value store > 6-Enthusiast runs the mounted app > > Maybe we could convince a host like Heroku to facilitate this. > Is this crazy? Any other ideas? > > -Philippe > > > On 7/13/2010 8:49 PM, Jenna Fox wrote: > > Another passing thought: It'd be very much in the spirit of freeform fun > little hacks if the camping website included a section of user created apps. > They would need to be moderated somehow, unless someone were to set up a > try-rubyish highly sandboxed environment to run them. It just seems like > there'd be no better way to show what Camping is all about than to have it's > very own website full of fun little examples of camping apps, with a way to > see the source code of each right in there. If you guys had something like > that, i'd love to contribute some quirky little multiplayer games, and an > extremely simple chat thing. :) > > What with rack mounts, this should be easy, right? > > Why did say at art & code that he didn't really care if the code editor > part of HetyH was really good - what mattered was the sharing. The forum. > The code messaging system. The apps which could talk to each other over the > web through the various APIs. That was the important part of hackety hack. I > think that's the important part of camping as well. The main reason I use > Camping over Sinatra and the likes is the way it feels so warm and fuzzy, > and I know if I have any troubles, I get to come talk to all you awesome > people. :) > > If we had the sandboxed thing, it'd be fairly trivial to include a little > cli app in the camping gem to upload the app in to a whyism or hetyh or > whatever account, where it could sit in a little bin of recent uploads, and > be attached to forum posts, or shared out like tinyurls. > > The most important part of all that is kids. Kids don't have web servers. > It's all well and good to have camping ourselves, but if we're to think for > one minute that we're helping kids learn ruby (which after all, was _why's > mission), we've got to be offering some fairly easy way for them to host > this stuff. > > Does anyone know much about sandboxing? Anyone know if it'd be particularly > difficult to do things like monkeypatch the IO class to effectively chroot > and secure a camping app? Can we disable `system calls` too? What's involved > in making something like that viable? Hosts like Dreamhost seem to already > be making use of Passenger to dynamically allocate ruby processes to apps, > so they can be booted up when requested and shut down after they idle for a > minute. :) > > — > Jenna Fox > http://creativepony.com/ > > > _______________________________________________ > Camping-list mailing list > camping-l...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
