BTW if you want to point a run.camping.io or 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> wrote:
> oh sure ! for me is not a problem - love 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> wrote:
>
>> 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 <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
>>
>>
>>
>> _______________________________________________
>> 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
