@David - sorted, both those subdomains now point to your machine. :)

—
Jenna


On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:

> BTW if you want to point a  run.camping.io (http://run.camping.io) or 
> host.camping.io (http://host.camping.io) or anything you like to  
> 66.116.108.12 will then be able to show an (hopefully) working demo using the 
> official domain ;)
>  
> On Sat, Mar 31, 2012 at 7:08 AM, david costa <gurugeek...@gmail.com 
> (mailto:gurugeek...@gmail.com)> wrote:
> > oh sure ! for me is not a problem - love camping.io (http://camping.io) as 
> > a domain !
> >  
> > first worry is to have a working system that is fairly stable and usable 
> > albeit it might be launched as alpha/beta anyway :)  
> >  
> >  
> > On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox <a...@creativepony.com 
> > (mailto:a...@creativepony.com)> wrote:
> > > We can just use a *.camping.io (http://camping.io) catchall entry
> > >  
> > >  
> > > On 31/03/2012, at 3:30 PM, david costa wrote:  
> > > > Hello Jenna,
> > > > we could use host.camping.io (http://host.camping.io/) or 
> > > > anything.camping.io (http://anything.camping.io/) for the frontend but 
> > > > if the server has to allow users to create myfancyapp.camping.io 
> > > > (http://myfancyapp.camping.io/) it would be complicated as I would need 
> > > > to run the camping.io (http://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 
> > > > (mailto: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 (http://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 
> > > > > > (http://camping.sh) or ruby.am (http://ruby.am/) e.g. 
> > > > > > myfancyapp.camping.sh (http://myfancyapp.camping.sh/) or 
> > > > > > myfancyapp.ruby.am (http://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 (mailto:Camping-list@rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list  
> > > > >  
> > > > > _______________________________________________
> > > > > Camping-list mailing list
> > > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > >  
> > > > _______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > > _______________________________________________
> > > Camping-list mailing list
> > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> >  
>  
> _______________________________________________
> Camping-list mailing list
> Camping-list@rubyforge.org (mailto: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

Reply via email to