We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa 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 <[email protected]> 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 >> [email protected] >> http://rubyforge.org/mailman/listinfo/camping-list > > > _______________________________________________ > Camping-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
