Actually setting up a reverse proxy gives better performance for the end user 
As you can have some sort of buffer between them. The Unicorn server takes care 
of whatever nginx asks for, and while it waits it can server whatever unicorn 
outputs. It doesn't have to wait for what it outputs itself to get done because 
you have a queue. Or something like that.

Some people actually out Apache to do PHP stuff while nginx acts as a reverse 
proxy and actually shows things to the user in the same way you'd do with 
Unicorn/Thin

But perhaps That's too much for a server ment to serve other peoples 
applications! Then you have to scale down the resources used.
-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

david costa <gurugeek...@gmail.com> skrev:

Hello Jenna !

I think that run rack applications the most efficient way seems to be phusion 
passenger that works with apache and nginx. It might work with other setups but 
it is not documented.

The other alternative to serve a camping application is to use a standard ruby 
webserver (thin, unicorn, etc.) and use either apache or nginx as reverse 
proxy. This should be more resource consuming as you would have both a 
thin/unicorn instance running and nginx.  The setup of passenger + apache seems 
to be very easy as you just drop the file with the camping app and it works. It 
can't really get more easier than this.


The camping file has to be called config.ru 
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_camping and 
this is the only way it works on my tests but I am sure that there is an easy 
way to work with several files or in a different way. 


Now if we want to use webdav apache has the module and with a digest 
authentication over ssl should be fairly secure. It also allows to limit the 
upload file size which could be useful (e.g. if someone is obviously trying to 
upload not a camping file !).


This is what I found so far as a possible solution but I am open to anything. I 
did try also an image that was using git/capistrano for remote deployment but 
somehow seemed an overkill to me and it didn't really work.  All I am doing is 
highly experimental so I am more than happy to see other idea/possibilities and 
see how far I can go with it.


I did think about webdav based on your idea which I think would make this 
different than heroku etc. like some beginners would not know git and might 
just like a little tent for their shiny camping app !


David





On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox <a...@creativepony.com> wrote:

Apache? What are your thoughts on that choice I am curious? :) 


—

Jenna


On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:

Thank you :D as soon as the DNS will propagate it should be live.

Some updates: now added the design from camping.io (working on the fonts) and I 
have narrowed down the probably easiest/best way to do it:

using Webdav module on apache. So there will be no issue with creating real 
server users and it should really be easily accessible  by anyone, anywhere. 
Working on some securities configurations to be sure that it works fine!



On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox <a...@creativepony.com> wrote:

@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 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



_______________________________________________
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


        Get the best selection of employment in atlanta sites here. Click Here 
to check 
        them out!
        
http://click.lavabit.com/fgzdikinbozpgnswnc13tpywy481ijz1ugm1mqa7yo617kgub7wb/ 

_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Reply via email to