Here is my progress on the server :) Spent several hours to try to work on a nginx + passenger setup on the cloud even using some pre-made ami with no success. It was also fairly slow vs. a real server (even on an XLarge instance).
So I went back to one spare brand new mac mini server quadcore i7 and I did install passenger on apache 2 without any major problem. All is fine and camping runs well pretty much on the fly by simply uploading your camping file in the relevant directory (which is pretty much what I wanted to achieve!) the sample fine (very rough I know) runs fine on the preview at http://bash.is/ :) Some small things you might have some ideas for: -On Passenger apparently camping runs without issues as config.ru (camping code on the config.ru file directly) see http://www.modrails.com/documentation/Users%20guide%20Apache.html#_camping I did try to use the camping book instructions (dreamhost) but for a reason or another it doesn't work. This is not a main issue thou as, if we allow to test 1 file apps automagically it can be renamed to config.ru as passenger wants but I am sure there is another way to do it perhaps; - I am getting the nasty internal error if I call a page like http://bash.is/lsdlksd but I do get a nice camping error for something like http://bash.is/blahh.html I am sure I can fix this small cosmetic thing easily thou need to dig a bit more on apache config TODO from my side: - If this testing would not include mysql or a db beside sqlite or flat would be probably easier as I won't need to make a script to set a db user etc. - A simple ruby or shell script to test quick upload and deployment of camping apps (this should required the creation of a new user + allow the user to connect and upload the files I guess). An alternative would be to have no new user created but, via a unique key, allow the user to see his app/change it etc. in his/her app sub-domain (myappl.domain.something) - Testing, Testing, Testing :) It looks exciting and I am sure it can come up as a pretty good solution. Webdav shouldn't be difficult at all and perhaps is the best way to do it so it would be way less geeky than heroku and well on one or more mac minis is fairly hedgy ! Cheers David On Sat, Mar 31, 2012 at 6:30 AM, david costa <gurugeek...@gmail.com> wrote: > Hello Jenna, > we could use host.camping.io or anything.camping.io for the frontend but > if the server has to allow users to create myfancyapp.camping.io it would > be complicated as I would need to run the camping.io DNS on the hosting > server to create the sub domains on the fly. I started working on it more > details on a separate email. > > I love your idea about the key-value database how can we implement this ? > Thanks > David > > > On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox <a...@creativepony.com> wrote: > >> Those both sound like brilliant servers! I'm not laughing at all. If my >> mac mini is good enough for sky rim, it's good enough for web hosting for >> sure! >> >> Can we just use camping.io? >> >> I think starting simple is a good idea. Databases are pretty cool among >> web developers for various reasons, but I think are totally unnecessary for >> most smaller experimental applications. For a beginner, I'm inclined to >> have key-value databases. A really simple key-value database would work >> like this: >> >> sections = key.hash.to_s(36).scan(/.{0,3}/) >> sections.delete "" >> Dir.mkdir sections[0…-1].join('/') >> File.open(sections.join('/') + '-value', 'w') do |file| >> file.write JSON.generate(value) >> end >> >> add in some file locking, and everything is pretty cool. It splits up the >> kevin to a series of about four directories and then a file, and >> conveniently "fff" in base36 is 19995, which is a very nice maximum number >> of things you'd ever want to put in a single directory if using something >> like EXT4 or HFS+. Of course, if using a B-Tree filesystem like reiser, >> btrfs, zfs there is no such limitation so you can skip the scanning joining >> thing and just open "database/#{key.hash}" and put a value in that. >> >> Pretty cool, no? It's really easy to turn something like that in to what >> seems from the outside to be a persistent hash. >> >> I was working on another thing called ForeverHash, which was the same >> sort of idea, but used flat files. If people are interested I'd be curious >> enough to revive that project with more of a CouchDB inspired design. >> >> I like all these filesystem based solutions (sqlite, crazy hash in >> folders, flat file key-value db's) because they can be backed up and >> restored via webdav or sftp or whatever, and you don't need to do any weird >> stuff of configuring which ports and usernames and passwords in your >> database abstraction. I prefer the idea of having a little key-value >> filesystem db written in clear straight forward ruby code, because it means >> kids learning can see how it works and hack at it - as nice as sqlite is, >> it is in no way transparent. You at least have to learn SQL if you want to >> play with it's innards, and possibly C. >> >> On 31/03/2012, at 3:22 AM, david costa wrote: >> >> Hello all, >> I am opening a separate topic just to brainstorm the idea of a free, >> simple camping deployment/hosting option. >> Now this is not about re-inventing the wheel as heroku already supports >> camping apps too. So this would be the ground idea: >> >> a) This would be entirely free - no paid plans to upgrade etc.; >> b) Eventually users should be able to deploy a camping application by >> launching something like camping-fly myapp in the command line and it would >> simply work (through a git push or similar) and make it available live in a >> custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or >> myfancyapp.ruby.am >> c) Database fanciness should also be available or at least sqlite/mysql >> >> Suggestion and ideas on how to achieve this are welcome (or professionals >> with the expertise willing to do a simple project based on this ) >> servers I can make available for this: >> >> Debian 6 >> Intel Core i7 3930K (6 x 3,20 GHz) >> RAM 64 GB >> 3000 GB HD + 256 MB SSD drive (very useful for databases, much faster) >> >> OR (don't laugh) >> >> Mac mini >> 2.0GHz quad-core Intel Core i7 >> 8GB memory >> 2X256GB Solid State Drive >> >> of course we would need to limit this to screened applicants to avoid any >> spammers/troublemakers >> >> Best Regards >> David >> _______________________________________________ >> 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 >> > >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
