From gurugeekphp at gmail.com Sun Apr 1 07:51:46 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 1 Apr 2012 09:51:46 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) And of course if you have a better idea for a setup let me know. Regards David On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: > WebDav for nginx: http://wiki.nginx.org/HttpDavModule > > Or you could implement webdav as an application nginx proxies to, just as > it proxies to ruby instances. > > ? > Jenna > > On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: > > On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: > > ** 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. > > > Mh I am not really sure it would be a better performance as it would be > anyway more than one process. I think that phusion passenger is pretty much > the most robust solution for this. > > > 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 > > > Well this would be even more load as two web servers will run at the same > time. Apache + Phusion passenger already lets you run .php or anything you > want. > > But this is not the issue really. I think this is all fine in term of mono > user. Question: if you have 100 users how do you configure it ? > How can you add webdav support on the top of the Nginx + unicorn setup ? > > > But perhaps That's too much for a server ment to serve other peoples > applications! Then you have to scale down the resources used. > > > I am open to anything but if I can't do something I might ask for some > brave volunteers to set it up as I really never tried anything else beside > for local/quick test deployment. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Sun Apr 1 08:03:00 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 1 Apr 2012 10:03:00 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: > Okay :D after many many hours of testing I am settled for nginx and > passenger. > live at http://run.camping.io/ > > I did try every apache combination (with passenger, with cgi, etc. etc.) > as is simply not really working fine. > I tried some other obscure web servers too but apparently this seems to > work fine for now :) other servers would run the app as CGI or FastCGI. I > am not worried about speed just ease of deployment and nginx with passenger > seems to do the job for now. The alternative is nginx as reverse proxy but > as Jenna rightly pointed out it would spawn a lot of thin instances that > might or might not be used. > > I did throw the sponge at Webdav on apache. It doesn't work as expected > and not with all clients. It seems more suitable to store quick files than > something else. > Can try tomorrow with nginx but perhaps it would be nicer to have a quick > camping hack to upload a file etc. but you can't just automate it entirely > else you can have people running malicious code automatically... > > I can do the shell scripts to create virtual users for nginx and dns. > Another option is to give a normal hosting for camping users. It wouldn't > be an issue to have 100-200 trusted users to have access to this e.g. we > can build a camping fronted for users to apply with a selection e.g. their > github account, why they want the deployment hosting etc. and then once > approved we would give them a normal account that would allow them to > upload files on SFTP and may be even shell (which BTW is something you > don't have on heroku and other services. Of course this could be protected > for security or given only to active people. > > How does heroku screens against abuses? > Anyway if some of you would like to be alpha users in this system let me > know, I will be glad to set you up as soon as I am done testing subdomains > etc. ;) > And of course if you have a better idea for a setup let me know. > > Regards > David > > > > > On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: > >> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >> >> Or you could implement webdav as an application nginx proxies to, just as >> it proxies to ruby instances. >> >> ? >> Jenna >> >> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >> >> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >> >> ** 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. >> >> >> Mh I am not really sure it would be a better performance as it would be >> anyway more than one process. I think that phusion passenger is pretty much >> the most robust solution for this. >> >> >> 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 >> >> >> Well this would be even more load as two web servers will run at the same >> time. Apache + Phusion passenger already lets you run .php or anything you >> want. >> >> But this is not the issue really. I think this is all fine in term of >> mono user. Question: if you have 100 users how do you configure it ? >> How can you add webdav support on the top of the Nginx + unicorn setup ? >> >> >> But perhaps That's too much for a server ment to serve other peoples >> applications! Then you have to scale down the resources used. >> >> >> I am open to anything but if I can't do something I might ask for some >> brave volunteers to set it up as I really never tried anything else beside >> for local/quick test deployment. >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterretief at gmail.com Sun Apr 1 08:23:42 2012 From: peterretief at gmail.com (Peter Retief) Date: Sun, 1 Apr 2012 10:23:42 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa wrote: > Ah I forgot > you can compare camping running on thin here > http://run.camping.io:3301/ > vs passenger at http://run.camping.io > > apparently db has some problems with fusion passenger (see > http://run.camping.io create HTML page and test HTML page. The same code > on thin works just fine... umhh oh no don't feel like more debugging ): > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: > >> Okay :D after many many hours of testing I am settled for nginx and >> passenger. >> live at http://run.camping.io/ >> >> I did try every apache combination (with passenger, with cgi, etc. etc.) >> as is simply not really working fine. >> I tried some other obscure web servers too but apparently this seems to >> work fine for now :) other servers would run the app as CGI or FastCGI. I >> am not worried about speed just ease of deployment and nginx with passenger >> seems to do the job for now. The alternative is nginx as reverse proxy but >> as Jenna rightly pointed out it would spawn a lot of thin instances that >> might or might not be used. >> >> I did throw the sponge at Webdav on apache. It doesn't work as expected >> and not with all clients. It seems more suitable to store quick files than >> something else. >> Can try tomorrow with nginx but perhaps it would be nicer to have a quick >> camping hack to upload a file etc. but you can't just automate it entirely >> else you can have people running malicious code automatically... >> >> I can do the shell scripts to create virtual users for nginx and dns. >> Another option is to give a normal hosting for camping users. It wouldn't >> be an issue to have 100-200 trusted users to have access to this e.g. we >> can build a camping fronted for users to apply with a selection e.g. their >> github account, why they want the deployment hosting etc. and then once >> approved we would give them a normal account that would allow them to >> upload files on SFTP and may be even shell (which BTW is something you >> don't have on heroku and other services. Of course this could be protected >> for security or given only to active people. >> >> How does heroku screens against abuses? >> Anyway if some of you would like to be alpha users in this system let me >> know, I will be glad to set you up as soon as I am done testing subdomains >> etc. ;) >> And of course if you have a better idea for a setup let me know. >> >> Regards >> David >> >> >> >> >> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >> >>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>> >>> Or you could implement webdav as an application nginx proxies to, just >>> as it proxies to ruby instances. >>> >>> ? >>> Jenna >>> >>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>> >>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >>> >>> ** 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. >>> >>> >>> Mh I am not really sure it would be a better performance as it would be >>> anyway more than one process. I think that phusion passenger is pretty much >>> the most robust solution for this. >>> >>> >>> 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 >>> >>> >>> Well this would be even more load as two web servers will run at the >>> same time. Apache + Phusion passenger already lets you run .php or anything >>> you want. >>> >>> But this is not the issue really. I think this is all fine in term of >>> mono user. Question: if you have 100 users how do you configure it ? >>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>> >>> >>> But perhaps That's too much for a server ment to serve other peoples >>> applications! Then you have to scale down the resources used. >>> >>> >>> I am open to anything but if I can't do something I might ask for some >>> brave volunteers to set it up as I really never tried anything else beside >>> for local/quick test deployment. >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Sun Apr 1 08:41:39 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 1 Apr 2012 10:41:39 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: Umh I doubt it was already here http://camping.io/Book/-Publishing-an-App#Using-Google-App-Engine but is far from an automated, one line /one upload system On Sun, Apr 1, 2012 at 10:23 AM, Peter Retief wrote: > Wonder if Google might help getting camping to run on app engine? > > > On 1 April 2012 10:03, david costa wrote: > >> Ah I forgot >> you can compare camping running on thin here >> http://run.camping.io:3301/ >> vs passenger at http://run.camping.io >> >> apparently db has some problems with fusion passenger (see >> http://run.camping.io create HTML page and test HTML page. The same code >> on thin works just fine... umhh oh no don't feel like more debugging ): >> >> >> >> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: >> >>> Okay :D after many many hours of testing I am settled for nginx and >>> passenger. >>> live at http://run.camping.io/ >>> >>> I did try every apache combination (with passenger, with cgi, etc. etc.) >>> as is simply not really working fine. >>> I tried some other obscure web servers too but apparently this seems to >>> work fine for now :) other servers would run the app as CGI or FastCGI. I >>> am not worried about speed just ease of deployment and nginx with passenger >>> seems to do the job for now. The alternative is nginx as reverse proxy but >>> as Jenna rightly pointed out it would spawn a lot of thin instances that >>> might or might not be used. >>> >>> I did throw the sponge at Webdav on apache. It doesn't work as expected >>> and not with all clients. It seems more suitable to store quick files than >>> something else. >>> Can try tomorrow with nginx but perhaps it would be nicer to have a >>> quick camping hack to upload a file etc. but you can't just automate it >>> entirely else you can have people running malicious code automatically... >>> >>> I can do the shell scripts to create virtual users for nginx and dns. >>> Another option is to give a normal hosting for camping users. It wouldn't >>> be an issue to have 100-200 trusted users to have access to this e.g. we >>> can build a camping fronted for users to apply with a selection e.g. their >>> github account, why they want the deployment hosting etc. and then once >>> approved we would give them a normal account that would allow them to >>> upload files on SFTP and may be even shell (which BTW is something you >>> don't have on heroku and other services. Of course this could be protected >>> for security or given only to active people. >>> >>> How does heroku screens against abuses? >>> Anyway if some of you would like to be alpha users in this system let me >>> know, I will be glad to set you up as soon as I am done testing subdomains >>> etc. ;) >>> And of course if you have a better idea for a setup let me know. >>> >>> Regards >>> David >>> >>> >>> >>> >>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >>> >>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>>> >>>> Or you could implement webdav as an application nginx proxies to, just >>>> as it proxies to ruby instances. >>>> >>>> ? >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>>> >>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >>>> >>>> ** 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. >>>> >>>> >>>> Mh I am not really sure it would be a better performance as it would be >>>> anyway more than one process. I think that phusion passenger is pretty much >>>> the most robust solution for this. >>>> >>>> >>>> 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 >>>> >>>> >>>> Well this would be even more load as two web servers will run at the >>>> same time. Apache + Phusion passenger already lets you run .php or anything >>>> you want. >>>> >>>> But this is not the issue really. I think this is all fine in term of >>>> mono user. Question: if you have 100 users how do you configure it ? >>>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>>> >>>> >>>> But perhaps That's too much for a server ment to serve other peoples >>>> applications! Then you have to scale down the resources used. >>>> >>>> >>>> I am open to anything but if I can't do something I might ask for some >>>> brave volunteers to set it up as I really never tried anything else beside >>>> for local/quick test deployment. >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>> >>> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 1 09:13:19 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 1 Apr 2012 19:13:19 +1000 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. ? Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: > Wonder if Google might help getting camping to run on app engine? > > On 1 April 2012 10:03, david costa wrote: > > Ah I forgot > > you can compare camping running on thin here > > http://run.camping.io:3301/ > > vs passenger at http://run.camping.io > > > > apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): > > > > > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: > > > Okay :D after many many hours of testing I am settled for nginx and passenger. > > > live at http://run.camping.io/ > > > > > > > > > I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. > > > I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. > > > > > > I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. > > > Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... > > > > > > I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. > > > > > > How does heroku screens against abuses? > > > Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) > > > And of course if you have a better idea for a setup let me know. > > > > > > Regards > > > David > > > > > > > > > > > > > > > On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: > > > > WebDav for nginx: http://wiki.nginx.org/HttpDavModule > > > > > > > > Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. > > > > > > > > ? > > > > Jenna > > > > > > > > > > > > On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: > > > > > > > > > > > > > On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: > > > > > > 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. > > > > > > > > > > Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. > > > > > > > > > > > > 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 > > > > > > > > > > Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. > > > > > > > > > > But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? > > > > > How can you add webdav support on the top of the Nginx + unicorn setup ? > > > > > > > > > > > > > > > > But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. > > > > > > > > > > > > > > > > I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. > > > > > _______________________________________________ > > > > > Camping-list mailing list > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Camping-list mailing list > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Sun Apr 1 10:25:03 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 01 Apr 2012 12:25:03 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> Message-ID: <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. ? Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) And of course if you have a better idea for a setup let me know. Regards David On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: WebDav for nginx: http://wiki.nginx.org/HttpDavModule Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. ? Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: 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. Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. 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 Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? How can you add webdav support on the top of the Nginx + unicorn setup ? But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Scarica Subito la Musica pi Trendy sul Tuo Telefonino http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 1 10:28:53 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 1 Apr 2012 20:28:53 +1000 Subject: dead easy deployment / Camping on the fly In-Reply-To: <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> Message-ID: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. ? Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: > Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > > Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. > > > > Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. > > > > Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). > > > > Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. > > > > ? > > Jenna > > > > > > On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: > > > > > Wonder if Google might help getting camping to run on app engine? > > > > > > On 1 April 2012 10:03, david costa wrote: > > > > Ah I forgot > > > > you can compare camping running on thin here > > > > http://run.camping.io:3301/ > > > > vs passenger at http://run.camping.io > > > > > > > > apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): > > > > > > > > > > > > > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: > > > > > Okay :D after many many hours of testing I am settled for nginx and passenger. > > > > > live at http://run.camping.io/ > > > > > > > > > > > > > > > I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. > > > > > I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. > > > > > > > > > > I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. > > > > > Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... > > > > > > > > > > I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. > > > > > > > > > > How does heroku screens against abuses? > > > > > Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) > > > > > And of course if you have a better idea for a setup let me know. > > > > > > > > > > Regards > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: > > > > > > WebDav for nginx: http://wiki.nginx.org/HttpDavModule > > > > > > > > > > > > Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. > > > > > > > > > > > > ? > > > > > > Jenna > > > > > > > > > > > > > > > > > > On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: > > > > > > > > > > > > > > > > > > > On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: > > > > > > > > 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. > > > > > > > > > > > > > > Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. > > > > > > > > > > > > > > But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? > > > > > > > How can you add webdav support on the top of the Nginx + unicorn setup ? > > > > > > > > > > > > > > > > > > > > > > But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. > > > > > > > > > > > > > > > > > > > > > > I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. > > > > > > > _______________________________________________ > > > > > > > Camping-list mailing list > > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Camping-list mailing list > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Camping-list mailing list > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > _______________________________________________ > > > Camping-list mailing list > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > Scarica Subito la Musica pi Trendy sul Tuo Telefonino > > http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Sun Apr 1 11:31:12 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 01 Apr 2012 13:31:12 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> Message-ID: <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. ? Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. ? Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) And of course if you have a better idea for a setup let me know. Regards David On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: WebDav for nginx: http://wiki.nginx.org/HttpDavModule Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. ? Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: 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. Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. 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 Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? How can you add webdav support on the top of the Nginx + unicorn setup ? But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Scarica Subito la Musica pi Trendy sul Tuo Telefonino http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Download de gratis Registry Scan om het problem te vinden! http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 1 11:49:12 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 1 Apr 2012 21:49:12 +1000 Subject: dead easy deployment / Camping on the fly In-Reply-To: <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: > Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? > > Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. > > ? > Jenna > > On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: > >> Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) >> -- >> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >> >> Jenna Fox skrev: >>> >>> Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. >>> >>> Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. >>> >>> Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). >>> >>> Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. >>> >>> ? >>> Jenna >>> >>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: >>> >>>> Wonder if Google might help getting camping to run on app engine? >>>> >>>> On 1 April 2012 10:03, david costa wrote: >>>>> Ah I forgot >>>>> you can compare camping running on thin here >>>>> http://run.camping.io:3301/ >>>>> vs passenger at http://run.camping.io >>>>> >>>>> apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): >>>>> >>>>> >>>>> >>>>> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: >>>>>> Okay :D after many many hours of testing I am settled for nginx and passenger. >>>>>> live at http://run.camping.io/ >>>>>> >>>>>> I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. >>>>>> I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. >>>>>> >>>>>> I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. >>>>>> Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... >>>>>> >>>>>> I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. >>>>>> >>>>>> How does heroku screens against abuses? >>>>>> Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) >>>>>> And of course if you have a better idea for a setup let me know. >>>>>> >>>>>> Regards >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >>>>>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>>>>>> >>>>>>> Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. >>>>>>> >>>>>>> ? >>>>>>> Jenna >>>>>>> >>>>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>>>>>> >>>>>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >>>>>>>>> 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. >>>>>>>> >>>>>>>> Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. >>>>>>>>> >>>>>>>>> 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 >>>>>>>> >>>>>>>> Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. >>>>>>>> >>>>>>>> But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? >>>>>>>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>>>>>>> >>>>>>>> >>>>>>>>> But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. >>>>>>>>> >>>>>>>> >>>>>>>> I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. >>>>>>>> _______________________________________________ >>>>>>>> Camping-list mailing list >>>>>>>> Camping-list at rubyforge.org >>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Camping-list mailing list >>>>>>> Camping-list at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/camping-list >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Camping-list mailing list >>>>> Camping-list at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> Scarica Subito la Musica pi Trendy sul Tuo Telefonino >>> http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > Download de gratis Registry Scan om het problem te vinden! > http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Sun Apr 1 12:38:03 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 01 Apr 2012 14:38:03 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. ? Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. ? Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: Okay :D after many many hours of testing I am settled for nginx and passenger. live at http://run.camping.io/ I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. How does heroku screens against abuses? Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) And of course if you have a better idea for a setup let me know. Regards David On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: WebDav for nginx: http://wiki.nginx.org/HttpDavModule Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. ? Jenna On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: 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. Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. 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 Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? How can you add webdav support on the top of the Nginx + unicorn setup ? But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Scarica Subito la Musica pi Trendy sul Tuo Telefonino http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Download de gratis Registry Scan om het problem te vinden! http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of names sites here. Click Here to check them out! http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Sun Apr 1 15:49:41 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 1 Apr 2012 17:49:41 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson wrote: > Okay then. But then we'd make sure that the applications don't have > privilege to install gems then. > > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: >> >> @Isak Anything run with the `backticks operator` runs with the same >> privileges as the process which launched them, if using system level >> sandboxing, or if using some crazy sandbox built in to ruby (which probably >> wouldn't be very good, but maybe good enough) it'd probably just disable >> backticks feature. >> >> >> On 01/04/2012, at 9:31 PM, Isak Andersson wrote: >> >> Well. Isn't it kind of possible to just hack the gem installation in >> using the ruby quotes that execute code on the system. I can't type them on >> the phone but I think you know what I mean. Kind of a security issue isn't >> it? >> >> Anyways. Perhaps we could offer some Gems to pick from that we think are >> quality! (rack_csrf, scrypt). >> -- >> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >> >> Jenna Fox skrev: >>> >>> I don't think we need to go as far as automatically installing gems - >>> securing ruby is a pretty big challenge, but securing gcc? no way. >>> >>> ? >>> Jenna >>> >>> On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: >>> >>> Remember that we should pretty much make a Gemfile mandatory if the >>> user makes use of gems other than Camping. For example, rack_csrf. And we >>> should make sure that dependencies get installed. :) >>> -- >>> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >>> >>> Jenna Fox skrev: >>> >>> Hm. I know the main guy responsible for App Engine, and, well, I >>> certainly wouldn't build a platform atop it - even aside from the huge >>> glaring issue that to have an app which can store data persistently, you >>> need to use google's proprietary database software. >>> >>> Heroku doesn't screen against abuse at all. Heroku is not a 'shared >>> hosting' provider. Their systems use the very finest jailing techniques to >>> lock the ruby process in to it's own little world. It has no writable >>> filesystem and it can only read what it absolutely needs to be able to read >>> to function. All data storage happens over the network on separated >>> database servers. The only type of abuse they need to be weary of is people >>> using their servers to do illegal things - bullying, sharing illegal >>> content, that sort of thing. They deal with that the same way any provider >>> does - wait till someone makes a complaint. Matz, inventor of ruby, works >>> for heroku making exactly this sort of stuff work extremely well. >>> >>> Still, it's not as friendly as it could be, and I personally think the >>> trade offs on heroku are not very good for beginners (you have to use a >>> complex database system, and cannot use the filesystem to store anything >>> but static assets). >>> >>> Good work getting this server up David! I'm pretty excited. It sounds >>> like you're having some pretty annoying deployment issues. As it's being >>> quite a hassle, perhaps we should be thinking more deeply about creating >>> our own special server for this task - something like the modified unicorn >>> I mentioned earlier somewhere. >>> >>> ? >>> Jenna >>> >>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: >>> >>> Wonder if Google might help getting camping to run on app engine? >>> >>> On 1 April 2012 10:03, david costa wrote: >>> >>> Ah I forgot >>> you can compare camping running on thin here >>> http://run.camping.io:3301/ >>> vs passenger at http://run.camping.io >>> >>> apparently db has some problems with fusion passenger (see >>> http://run.camping.io create HTML page and test HTML page. The same >>> code on thin works just fine... umhh oh no don't feel like more debugging ): >>> >>> >>> >>> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: >>> >>> Okay :D after many many hours of testing I am settled for nginx and >>> passenger. >>> live at http://run.camping.io/ >>> >>> I did try every apache combination (with passenger, with cgi, etc. etc.) >>> as is simply not really working fine. >>> I tried some other obscure web servers too but apparently this seems to >>> work fine for now :) other servers would run the app as CGI or FastCGI. I >>> am not worried about speed just ease of deployment and nginx with passenger >>> seems to do the job for now. The alternative is nginx as reverse proxy but >>> as Jenna rightly pointed out it would spawn a lot of thin instances that >>> might or might not be used. >>> >>> I did throw the sponge at Webdav on apache. It doesn't work as expected >>> and not with all clients. It seems more suitable to store quick files than >>> something else. >>> Can try tomorrow with nginx but perhaps it would be nicer to have a >>> quick camping hack to upload a file etc. but you can't just automate it >>> entirely else you can have people running malicious code automatically... >>> >>> I can do the shell scripts to create virtual users for nginx and dns. >>> Another option is to give a normal hosting for camping users. It wouldn't >>> be an issue to have 100-200 trusted users to have access to this e.g. we >>> can build a camping fronted for users to apply with a selection e.g. their >>> github account, why they want the deployment hosting etc. and then once >>> approved we would give them a normal account that would allow them to >>> upload files on SFTP and may be even shell (which BTW is something you >>> don't have on heroku and other services. Of course this could be protected >>> for security or given only to active people. >>> >>> How does heroku screens against abuses? >>> Anyway if some of you would like to be alpha users in this system let me >>> know, I will be glad to set you up as soon as I am done testing subdomains >>> etc. ;) >>> And of course if you have a better idea for a setup let me know. >>> >>> Regards >>> David >>> >>> >>> >>> >>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >>> >>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>> >>> Or you could implement webdav as an application nginx proxies to, just >>> as it proxies to ruby instances. >>> >>> ? >>> Jenna >>> >>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>> >>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >>> >>> ** 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. >>> >>> >>> Mh I am not really sure it would be a better performance as it would be >>> anyway more than one process. I think that phusion passenger is pretty much >>> the most robust solution for this. >>> >>> >>> 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 >>> >>> >>> Well this would be even more load as two web servers will run at the >>> same time. Apache + Phusion passenger already lets you run .php or anything >>> you want. >>> >>> But this is not the issue really. I think this is all fine in term of >>> mono user. Question: if you have 100 users how do you configure it ? >>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>> >>> >>> But perhaps That's too much for a server ment to serve other peoples >>> applications! Then you have to scale down the resources used. >>> >>> >>> I am open to anything but if I can't do something I might ask for some >>> brave volunteers to set it up as I really never tried anything else beside >>> for local/quick test deployment. >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> Scarica Subito la Musica pi Trendy sul Tuo Telefonino >>> >>> http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> Download de gratis Registry Scan om het problem te vinden! >>> >>> http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ >>> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Get the best selection of names sites here. Click Here to check them out! > > http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/ > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Sun Apr 1 17:38:19 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Sun, 1 Apr 2012 18:38:19 +0100 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: <2E15F319-DEBB-4C49-8DF5-1314AEE45041@innotts.co.uk> A bit late in the day, but (quick and probably uninformed thought, given the volume of messages I just skimmed) might rvm help manage Ruby installs/updates/gems safely? - DaveE > Hello again ! :) > well in theory we can chrot jail users but the best way is to > install the gems that people need perhaps the most used ones. It > will then work system wide ! > The big question is who will be your typical user. If is someone you > trust then you can give them even limited ssh + sftp :) > > Back to my ignorance: how do you folks run camping in a server ? do > you use fcgi ? At work we used to run a fairly big production > environment made of rails running with lighthtp and fcgi. If we > were to run this as a dead simple fcgi setup did anyone set this up? > I have tried all the instructions github on how to set this up with > dispatcher.fcgi but failed miserably. > > I would can get the server installed + fcgi but how to run camping > apps from there is a bit of a mystery. > > I am slightly frustrated because of passenger not making a simple > create page/test page http://camping.sh/ working. I know is not the > app as it works at http://camping.sh:3301/ > Unicorn: I think you would be back to have nginx as a reverse proxy > for that which can present some problems for example, default port > is 3301 for camping. So you would need a script to check which port > is free and run then camping --port so seems a bit complicated. > > Thanks > David > > > On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson > wrote: > Okay then. But then we'd make sure that the applications don't have > privilege to install gems then. > > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min > f?ordighet. > > Jenna Fox skrev: > @Isak Anything run with the `backticks operator` runs with the same > privileges as the process which launched them, if using system level > sandboxing, or if using some crazy sandbox built in to ruby (which > probably wouldn't be very good, but maybe good enough) it'd probably > just disable backticks feature. > > > On 01/04/2012, at 9:31 PM, Isak Andersson wrote: > >> Well. Isn't it kind of possible to just hack the gem installation >> in using the ruby quotes that execute code on the system. I can't >> type them on the phone but I think you know what I mean. Kind of a >> security issue isn't it? >> >> Anyways. Perhaps we could offer some Gems to pick from that we >> think are quality! (rack_csrf, scrypt). >> -- >> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min >> f?ordighet. >> >> Jenna Fox skrev: >> I don't think we need to go as far as automatically installing gems >> - securing ruby is a pretty big challenge, but securing gcc? no way. >> >> ? >> Jenna >> >> On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: >> >>> Remember that we should pretty much make a Gemfile mandatory if >>> the user makes use of gems other than Camping. For example, >>> rack_csrf. And we should make sure that dependencies get >>> installed. :) >>> -- >>> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min >>> f?ordighet. >>> >>> Jenna Fox skrev: >>>> >>>> Hm. I know the main guy responsible for App Engine, and, well, I >>>> certainly wouldn't build a platform atop it - even aside from the >>>> huge glaring issue that to have an app which can store data >>>> persistently, you need to use google's proprietary database >>>> software. >>>> >>>> Heroku doesn't screen against abuse at all. Heroku is not a >>>> 'shared hosting' provider. Their systems use the very finest >>>> jailing techniques to lock the ruby process in to it's own little >>>> world. It has no writable filesystem and it can only read what it >>>> absolutely needs to be able to read to function. All data storage >>>> happens over the network on separated database servers. The only >>>> type of abuse they need to be weary of is people using their >>>> servers to do illegal things - bullying, sharing illegal content, >>>> that sort of thing. They deal with that the same way any provider >>>> does - wait till someone makes a complaint. Matz, inventor of >>>> ruby, works for heroku making exactly this sort of stuff work >>>> extremely well. >>>> >>>> Still, it's not as friendly as it could be, and I personally >>>> think the trade offs on heroku are not very good for beginners >>>> (you have to use a complex database system, and cannot use the >>>> filesystem to store anything but static assets). >>>> >>>> Good work getting this server up David! I'm pretty excited. It >>>> sounds like you're having some pretty annoying deployment issues. >>>> As it's being quite a hassle, perhaps we should be thinking more >>>> deeply about creating our own special server for this task - >>>> something like the modified unicorn I mentioned earlier somewhere. >>>> >>>> ? >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: >>>> >>>>> Wonder if Google might help getting camping to run on app engine? >>>>> >>>>> On 1 April 2012 10:03, david costa wrote: >>>>>> Ah I forgot >>>>>> you can compare camping running on thin here >>>>>> http://run.camping.io:3301/ >>>>>> vs passenger at http://run.camping.io >>>>>> >>>>>> apparently db has some problems with fusion passenger (see http://run.camping.io >>>>>> create HTML page and test HTML page. The same code on thin >>>>>> works just fine... umhh oh no don't feel like more debugging ): >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Apr 1, 2012 at 9:51 AM, david costa >>>>> > wrote: >>>>>>> Okay :D after many many hours of testing I am settled for >>>>>>> nginx and passenger. >>>>>>> live at http://run.camping.io/ >>>>>>> >>>>>>> I did try every apache combination (with passenger, with cgi, >>>>>>> etc. etc.) as is simply not really working fine. >>>>>>> I tried some other obscure web servers too but apparently this >>>>>>> seems to work fine for now :) other servers would run the app >>>>>>> as CGI or FastCGI. I am not worried about speed just ease of >>>>>>> deployment and nginx with passenger seems to do the job for >>>>>>> now. The alternative is nginx as reverse proxy but as Jenna >>>>>>> rightly pointed out it would spawn a lot of thin instances >>>>>>> that might or might not be used. >>>>>>> >>>>>>> I did throw the sponge at Webdav on apache. It doesn't work as >>>>>>> expected and not with all clients. It seems more suitable to >>>>>>> store quick files than something else. >>>>>>> Can try tomorrow with nginx but perhaps it would be nicer to >>>>>>> have a quick camping hack to upload a file etc. but you can't >>>>>>> just automate it entirely else you can have people running >>>>>>> malicious code automatically... >>>>>>> >>>>>>> I can do the shell scripts to create virtual users for nginx >>>>>>> and dns. Another option is to give a normal hosting for >>>>>>> camping users. It wouldn't be an issue to have 100-200 trusted >>>>>>> users to have access to this e.g. we can build a camping >>>>>>> fronted for users to apply with a selection e.g. their github >>>>>>> account, why they want the deployment hosting etc. and then >>>>>>> once approved we would give them a normal account that would >>>>>>> allow them to upload files on SFTP and may be even shell >>>>>>> (which BTW is something you don't have on heroku and other >>>>>>> services. Of course this could be protected for security or >>>>>>> given only to active people. >>>>>>> >>>>>>> How does heroku screens against abuses? >>>>>>> Anyway if some of you would like to be alpha users in this >>>>>>> system let me know, I will be glad to set you up as soon as I >>>>>>> am done testing subdomains etc. ;) >>>>>>> And of course if you have a better idea for a setup let me know. >>>>>>> >>>>>>> Regards >>>>>>> David >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox >>>>>>> wrote: >>>>>>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>>>>>>> >>>>>>>> Or you could implement webdav as an application nginx proxies >>>>>>>> to, just as it proxies to ruby instances. >>>>>>>> >>>>>>>> ? >>>>>>>> Jenna >>>>>>>> >>>>>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>>>>>>> >>>>>>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson >>>>>>>> > wrote: >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Mh I am not really sure it would be a better performance as >>>>>>>>> it would be anyway more than one process. I think that >>>>>>>>> phusion passenger is pretty much the most robust solution >>>>>>>>> for this. >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> Well this would be even more load as two web servers will >>>>>>>>> run at the same time. Apache + Phusion passenger already >>>>>>>>> lets you run .php or anything you want. >>>>>>>>> >>>>>>>>> But this is not the issue really. I think this is all fine >>>>>>>>> in term of mono user. Question: if you have 100 users how do >>>>>>>>> you configure it ? >>>>>>>>> How can you add webdav support on the top of the Nginx + >>>>>>>>> unicorn setup ? >>>>>>>>> >>>>>>>>> >>>>>>>>>> But perhaps That's too much for a server ment to serve >>>>>>>>>> other peoples applications! Then you have to scale down the >>>>>>>>>> resources used. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I am open to anything but if I can't do something I might >>>>>>>>> ask for some brave volunteers to set it up as I really never >>>>>>>>> tried anything else beside for local/quick test deployment. >>>>>>>>> _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 1 23:02:21 2012 From: a at creativepony.com (Jenna Fox) Date: Mon, 2 Apr 2012 09:02:21 +1000 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Oh gods not RVM. This setup does not need another layer of complexity. On my own server, I use five thins, which run all the time, on a set of five ports which nginx proxy to. To run hundreds of camping apps, this sort of persistent setup isn't viable. CGI would work, but could be a little slow for some more complex applications. A better solution is, in my opinion, to fork. thins or unicorns could be connected with a simple camping app which forks on each request, loads a users app in to that instance, runs it once, then closes. It would be faster than CGI, not too hard to implement, and wouldn't take more resources to install more apps on the server. It also makes for a convenient place to run code before the user's application runs, which maybe useful for sandboxing or setting up web accessible logging. From what I've heard chroot isn't a good way to jail processes - it doesn't restrict network access, and it's often possible to escape the jail. Consider this: A script loads the socket library and opens port after port until computer fails. Disable the socket library? have the ruby process store a binary inside it, which it saves to a file, sets execute permission, then runs - it does the same thing. Another attack would be a fork bomb. Security is really complex. How did dot geek deal with it? did you ever have trouble with malicious users? ? Jenna On Monday, 2 April 2012 at 1:49 AM, david costa wrote: > Hello again ! :) > well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! > The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) > > Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. > > I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. > > I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ > Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. > > Thanks > David > > > On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson wrote: > > Okay then. But then we'd make sure that the applications don't have privilege to install gems then. > > > > -- > > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > > > Jenna Fox skrev: > > > @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. > > > > > > > > > On 01/04/2012, at 9:31 PM, Isak Andersson wrote: > > > > Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? > > > > > > > > Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). > > > > -- > > > > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > > > > > > > Jenna Fox skrev: > > > > > I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. > > > > > > > > > > ? > > > > > Jenna > > > > > > > > > > > > > > > On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: > > > > > > > > > > > Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) > > > > > > -- > > > > > > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > > > > > > > > > > > Jenna Fox skrev: > > > > > > > Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. > > > > > > > > > > > > > > Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. > > > > > > > > > > > > > > Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). > > > > > > > > > > > > > > Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. > > > > > > > > > > > > > > ? > > > > > > > Jenna > > > > > > > > > > > > > > > > > > > > > On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: > > > > > > > > > > > > > > > Wonder if Google might help getting camping to run on app engine? > > > > > > > > > > > > > > > > On 1 April 2012 10:03, david costa wrote: > > > > > > > > > Ah I forgot > > > > > > > > > you can compare camping running on thin here > > > > > > > > > http://run.camping.io:3301/ > > > > > > > > > vs passenger at http://run.camping.io (http://run.camping.io/) > > > > > > > > > > > > > > > > > > apparently db has some problems with fusion passenger (see http://run.camping.io (http://run.camping.io/) create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: > > > > > > > > > > Okay :D after many many hours of testing I am settled for nginx and passenger. > > > > > > > > > > live at http://run.camping.io/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I did try every apache combination (with passenger, with cgi, etc. etc.) as is simply not really working fine. > > > > > > > > > > I tried some other obscure web servers too but apparently this seems to work fine for now :) other servers would run the app as CGI or FastCGI. I am not worried about speed just ease of deployment and nginx with passenger seems to do the job for now. The alternative is nginx as reverse proxy but as Jenna rightly pointed out it would spawn a lot of thin instances that might or might not be used. > > > > > > > > > > > > > > > > > > > > I did throw the sponge at Webdav on apache. It doesn't work as expected and not with all clients. It seems more suitable to store quick files than something else. > > > > > > > > > > Can try tomorrow with nginx but perhaps it would be nicer to have a quick camping hack to upload a file etc. but you can't just automate it entirely else you can have people running malicious code automatically... > > > > > > > > > > > > > > > > > > > > I can do the shell scripts to create virtual users for nginx and dns. Another option is to give a normal hosting for camping users. It wouldn't be an issue to have 100-200 trusted users to have access to this e.g. we can build a camping fronted for users to apply with a selection e.g. their github account, why they want the deployment hosting etc. and then once approved we would give them a normal account that would allow them to upload files on SFTP and may be even shell (which BTW is something you don't have on heroku and other services. Of course this could be protected for security or given only to active people. > > > > > > > > > > > > > > > > > > > > How does heroku screens against abuses? > > > > > > > > > > Anyway if some of you would like to be alpha users in this system let me know, I will be glad to set you up as soon as I am done testing subdomains etc. ;) > > > > > > > > > > And of course if you have a better idea for a setup let me know. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: > > > > > > > > > > > WebDav for nginx: http://wiki.nginx.org/HttpDavModule > > > > > > > > > > > > > > > > > > > > > > Or you could implement webdav as an application nginx proxies to, just as it proxies to ruby instances. > > > > > > > > > > > > > > > > > > > > > > ? > > > > > > > > > > > Jenna > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > Mh I am not really sure it would be a better performance as it would be anyway more than one process. I think that phusion passenger is pretty much the most robust solution for this. > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > Well this would be even more load as two web servers will run at the same time. Apache + Phusion passenger already lets you run .php or anything you want. > > > > > > > > > > > > > > > > > > > > > > > > But this is not the issue really. I think this is all fine in term of mono user. Question: if you have 100 users how do you configure it ? > > > > > > > > > > > > How can you add webdav support on the top of the Nginx + unicorn setup ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But perhaps That's too much for a server ment to serve other peoples applications! Then you have to scale down the resources used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am open to anything but if I can't do something I might ask for some brave volunteers to set it up as I really never tried anything else beside for local/quick test deployment. > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Camping-list mailing list > > > > > > > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Camping-list mailing list > > > > > > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Camping-list mailing list > > > > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Camping-list mailing list > > > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scarica Subito la Musica pi Trendy sul Tuo Telefonino > > > > > > > http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ > > > > > > _______________________________________________ > > > > > > Camping-list mailing list > > > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Download de gratis Registry Scan om het problem te vinden! > > > > > http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ _______________________________________________ > > > > Camping-list mailing list > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > Get the best selection of names sites here. Click Here to check them out! > > http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/ > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nerdfunk at gmail.com Mon Apr 2 00:46:14 2012 From: nerdfunk at gmail.com (adam moore) Date: Mon, 2 Apr 2012 09:46:14 +0900 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: I have no idea but could something like ZeroVM be useful? http://zerovm.org/ On Monday, April 2, 2012, Jenna Fox wrote: > Oh gods not RVM. This setup does not need another layer of complexity. > > On my own server, I use five thins, which run all the time, on a set of > five ports which nginx proxy to. To run hundreds of camping apps, this sort > of persistent setup isn't viable. CGI would work, but could be a little > slow for some more complex applications. A better solution is, in my > opinion, to fork. thins or unicorns could be connected with a simple > camping app which forks on each request, loads a users app in to that > instance, runs it once, then closes. It would be faster than CGI, not too > hard to implement, and wouldn't take more resources to install more apps on > the server. It also makes for a convenient place to run code before the > user's application runs, which maybe useful for sandboxing or setting up > web accessible logging. > > From what I've heard chroot isn't a good way to jail processes - it > doesn't restrict network access, and it's often possible to escape the > jail. Consider this: A script loads the socket library and opens port after > port until computer fails. Disable the socket library? have the ruby > process store a binary inside it, which it saves to a file, sets execute > permission, then runs - it does the same thing. Another attack would be a > fork bomb. > > Security is really complex. How did dot geek deal with it? did you ever > have trouble with malicious users? > > ? > Jenna > > On Monday, 2 April 2012 at 1:49 AM, david costa wrote: > > Hello again ! :) > well in theory we can chrot jail users but the best way is to install the > gems that people need perhaps the most used ones. It will then work system > wide ! > The big question is who will be your typical user. If is someone you trust > then you can give them even limited ssh + sftp :) > > Back to my ignorance: how do you folks run camping in a server ? do you > use fcgi ? At work we used to run a fairly big production environment made > of rails running with lighthtp and fcgi. If we were to run this as a dead > simple fcgi setup did anyone set this up? I have tried all the instructions > github on how to set this up with dispatcher.fcgi but failed miserably. > > I would can get the server installed + fcgi but how to run camping apps > from there is a bit of a mystery. > > I am slightly frustrated because of passenger not making a simple create > page/test page http://camping.sh/ working. I know is not the app as it > works at http://camping.sh:3301/ > Unicorn: I think you would be back to have nginx as a reverse proxy for > that which can present some problems for example, default port is 3301 for > camping. So you would need a script to check which port is free and run > then camping --port so seems a bit complicated. > > Thanks > David > > > On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson wrote: > > Okay then. But then we'd make sure that the applications don't have > privilege to install gems then. > > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > > @Isak Anything run with the `backticks operator` runs with the same > privileges as the process which launched them, if using system level > sandboxing, or if using some crazy sandbox built in to ruby (which probably > wouldn't be very good, but maybe good enough) it'd probably just disable > backticks feature. > > > On 01/04/2012, at 9:31 PM, Isak Andersson wrote: > > Well. Isn't it kind of possible to just hack the gem installation in using > the ruby quotes that execute code on the system. I can't type them on the > phone but I think you know what I mean. Kind of a security issue isn't it? > > Anyways. Perhaps we could offer some Gems to pick from that we think are > quality! (rack_csrf, scrypt). > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > > I don't think we need to go as far as automatically installing gems - > securing ruby is a pretty big challenge, but securing gcc? no way. > > ? > Jenna > > On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: > > Remember that we should pretty much make a Gemfile mandatory if the user > makes use of gems other than Camping. For example, rack_csrf. And we should > make sure that dependencies get installed. :) > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > > Hm. I know the main guy responsible for App Engine, and, well, I certainly > wouldn't build a platform atop it - even aside from the huge glaring issue > that to have an app which can store data persistently, you need to use > google's proprietary database software. > > Heroku doesn't screen against abuse at all. Heroku is not a 'shared > hosting' provider. Their systems use the very finest jailing techniques to > lock the ruby process in to it's own little world. It has no writable > filesystem and it can only read what it absolutely needs to be able to read > to function. All data storage happens over the network on separated datab > > -- ----=^.^=--- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 2 01:40:39 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 2 Apr 2012 03:40:39 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: On Mon, Apr 2, 2012 at 1:02 AM, Jenna Fox wrote: > Oh gods not RVM. This setup does not need another layer of complexity. > > On my own server, I use five thins, which run all the time, on a set of > five ports which nginx proxy to. To run hundreds of camping apps, this sort > of persistent setup isn't viable. CGI would work, but could be a little > slow for some more complex applications. A better solution is, in my > opinion, to fork. thins or unicorns could be connected with a simple > camping app which forks on each request, loads a users app in to that > instance, runs it once, then closes. It would be faster than CGI, not too > hard to implement, and wouldn't take more resources to install more apps on > the server. It also makes for a convenient place to run code before the > user's application runs, which maybe useful for sandboxing or setting up > web accessible logging. > > I am pretty ignorant on unicorn but I did fix the db error which was fixed by adding HomePage::Models::Base.establish_connection( :adapter => 'sqlite3', :database => '/home/gurugeek/.camping.db') to the end of the file so now it is working with sqlite support http://run.camping.io Ironically this goes back to the first question I wrote to Isak on where was the famous .camping.db that was mentioned in the blog example. For a beginner it takes some googling to find out but now I know so not a big deal ! So we have now a working system with nginx and passenger. This is extremely simple as a user will have to upload the files on this folder and is ready to go. I have already tested multiple host on nginx and it works fine and is much easier to setup than apache. I already coded a add_camping_user bash script to automate user creation + nginx configuration updating and restart. So I am open to any fork but we have a working system (currently on linux but working fine also on mac see it running at http://basic.sh/) that should work fine with any basic camping app + sqlite too. I actually think that the guys at phusion did a good job on passenger as it is well documented, easy to install (if you use nginx it would even install nginx for you if you want) and they even included a camping example on the site. Whomever wants to try the system can email me and I will be glad to open an account for testing purposes. >From what I've heard chroot isn't a good way to jail processes - it doesn't > restrict network access, and it's often possible to escape the jail. > Consider this: A script loads the socket library and opens port after port > until computer fails. Disable the socket library? have the ruby process > store a binary inside it, which it saves to a file, sets execute > permission, then runs - it does the same thing. Another attack would be a > fork bomb. > > Security is really complex. How did dot geek deal with it? did you ever > have trouble with malicious users? > > You are very right on security :'( The first idea is to create users without shell so they can use sftp but not ssh. Then ssh could be granted to admins or people helping in the project. Now this doesn't solve security entirely as you can still run malicious stuff via sftp. In dotgeek we had a two tier screening process: a) the online form asked for an authorization key. This was given out on IRC after people explained why they wanted the hosting etc to some admins; b) the online form asked some general information about the user and why he wanted the free hosting. Based on the reply we would activate the account or not. Now this was on the pre-github and Facebook era perhaps now it is a bit easier to find out if someone is genuine or not. Still we had many issues with dotgeek. We discovered some people running even paypal clones to grab details from users. Emails was another issues we had to deal with and many other small ones but in short the only way to keep it decent was to screen people. I am too new to ruby and camping to know what kind of hostile commands you can run from a script but I guess it is as dangerous as php (or perhaps not?). If we want to automate some stuff I can easily build a script to find out if an uploaded file is a camping script or not. At least from the appearance. You already told me how Heroku does it and seems pretty smart. Is engine yard doing something similar ? There are essentially two options: a) Allow users to upload an app and their files via camping backed online interface. This can be fairly easy and would have a zero knowledge required. It would be somehow the opposite of other services that require you to use git and similar. The issue is how to evaluate what is uploaded. If we have some details about the user we could run a manual check the first 1-3 times and then set him/her free. If there is another way to evaluate files securely (e.g. is a camping app and not something malicious) it would be even better ! b) Open standard unix users. This is not an issue in terms of capacity but more security in the sense of users being then able to run anything on their space by uploading on sftp. It could be even used to store unwanted files etc. This option could be also used in conjunction with option a) but only after a user has proven that is not ill intended. Another important point on dotgeek was the "php marathon" because that was one of the rules that the participating app should run on PHP 5 and back in the days there was no hosting providing that. So perhaps, once we get this running, we can do a small contest with prizes and see if people are interested in showing off their ideas with camping. I am saying this just to go to the next stage (after screencasts and on the fly app working) to then launch it and drive some more visitors. Else it would be pointless as with heroku and so many good services this might sound a bit bare bones to some ! David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 2 01:47:53 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 2 Apr 2012 03:47:53 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Hi Adam :) On Mon, Apr 2, 2012 at 2:46 AM, adam moore wrote: > I have no idea but could something like ZeroVM be useful? > > http://zerovm.org/ > > Well this is entirely different :) If you give a virtualized environment the user is pretty much on his own and can do/install anything as in a separate server. Per see is a good idea but the question is how camping as a community would gain out of it. Another issue is you do have already free competition http://aws.amazon.com/free/ with a pretty decent offer if you ask me (which I am sure many are using). My idea was just to make easier for learners to run and deploy a camping app e.g. from command line camping-fly BestApp and then you would see it live at bestapp.camping.iosimple yet effective as I don't think any other framework, micro or not, offers this out of the box. As camping is a micro framework that might be used for smallish projects this would work fine e.g. you are working on a quick idea and you want to show it to some friends, colleagues or need to use it for a class project and there you go. Low learning curve ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 2 08:45:30 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 2 Apr 2012 10:45:30 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Hi, As I already mentioned I use Camping with fcgi in production. If It is your choice (and not passenger), I will help you set it up. On Sun, Apr 1, 2012 at 5:49 PM, david costa wrote: > Hello again ! :) > well in theory we can chrot jail users but the best way is to install the > gems that people need perhaps the most used ones. It will then work system > wide ! > The big question is who will be your typical user. If is someone you trust > then you can give them even limited ssh + sftp :) > > Back to my ignorance: how do you folks run camping in a server ? do you > use fcgi ? At work we used to run a fairly big production environment made > of rails running with lighthtp and fcgi. If we were to run this as a dead > simple fcgi setup did anyone set this up? I have tried all the instructions > github on how to set this up with dispatcher.fcgi but failed miserably. > > I would can get the server installed + fcgi but how to run camping apps > from there is a bit of a mystery. > > I am slightly frustrated because of passenger not making a simple create > page/test page http://camping.sh/ working. I know is not the app as it > works at http://camping.sh:3301/ > Unicorn: I think you would be back to have nginx as a reverse proxy for > that which can present some problems for example, default port is 3301 for > camping. So you would need a script to check which port is free and run > then camping --port so seems a bit complicated. > > Thanks > David > > > > On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson wrote: > >> Okay then. But then we'd make sure that the applications don't have >> privilege to install gems then. >> >> -- >> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >> >> Jenna Fox skrev: >>> >>> @Isak Anything run with the `backticks operator` runs with the same >>> privileges as the process which launched them, if using system level >>> sandboxing, or if using some crazy sandbox built in to ruby (which probably >>> wouldn't be very good, but maybe good enough) it'd probably just disable >>> backticks feature. >>> >>> >>> On 01/04/2012, at 9:31 PM, Isak Andersson wrote: >>> >>> Well. Isn't it kind of possible to just hack the gem installation in >>> using the ruby quotes that execute code on the system. I can't type them on >>> the phone but I think you know what I mean. Kind of a security issue isn't >>> it? >>> >>> Anyways. Perhaps we could offer some Gems to pick from that we think are >>> quality! (rack_csrf, scrypt). >>> -- >>> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >>> >>> Jenna Fox skrev: >>>> >>>> I don't think we need to go as far as automatically installing gems - >>>> securing ruby is a pretty big challenge, but securing gcc? no way. >>>> >>>> ? >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: >>>> >>>> Remember that we should pretty much make a Gemfile mandatory if the >>>> user makes use of gems other than Camping. For example, rack_csrf. And we >>>> should make sure that dependencies get installed. :) >>>> -- >>>> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >>>> >>>> Jenna Fox skrev: >>>> >>>> Hm. I know the main guy responsible for App Engine, and, well, I >>>> certainly wouldn't build a platform atop it - even aside from the huge >>>> glaring issue that to have an app which can store data persistently, you >>>> need to use google's proprietary database software. >>>> >>>> Heroku doesn't screen against abuse at all. Heroku is not a 'shared >>>> hosting' provider. Their systems use the very finest jailing techniques to >>>> lock the ruby process in to it's own little world. It has no writable >>>> filesystem and it can only read what it absolutely needs to be able to read >>>> to function. All data storage happens over the network on separated >>>> database servers. The only type of abuse they need to be weary of is people >>>> using their servers to do illegal things - bullying, sharing illegal >>>> content, that sort of thing. They deal with that the same way any provider >>>> does - wait till someone makes a complaint. Matz, inventor of ruby, works >>>> for heroku making exactly this sort of stuff work extremely well. >>>> >>>> Still, it's not as friendly as it could be, and I personally think the >>>> trade offs on heroku are not very good for beginners (you have to use a >>>> complex database system, and cannot use the filesystem to store anything >>>> but static assets). >>>> >>>> Good work getting this server up David! I'm pretty excited. It sounds >>>> like you're having some pretty annoying deployment issues. As it's being >>>> quite a hassle, perhaps we should be thinking more deeply about creating >>>> our own special server for this task - something like the modified unicorn >>>> I mentioned earlier somewhere. >>>> >>>> ? >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: >>>> >>>> Wonder if Google might help getting camping to run on app engine? >>>> >>>> On 1 April 2012 10:03, david costa wrote: >>>> >>>> Ah I forgot >>>> you can compare camping running on thin here >>>> http://run.camping.io:3301/ >>>> vs passenger at http://run.camping.io >>>> >>>> apparently db has some problems with fusion passenger (see >>>> http://run.camping.io create HTML page and test HTML page. The same >>>> code on thin works just fine... umhh oh no don't feel like more debugging ): >>>> >>>> >>>> >>>> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: >>>> >>>> Okay :D after many many hours of testing I am settled for nginx and >>>> passenger. >>>> live at http://run.camping.io/ >>>> >>>> I did try every apache combination (with passenger, with cgi, etc. >>>> etc.) as is simply not really working fine. >>>> I tried some other obscure web servers too but apparently this seems to >>>> work fine for now :) other servers would run the app as CGI or FastCGI. I >>>> am not worried about speed just ease of deployment and nginx with passenger >>>> seems to do the job for now. The alternative is nginx as reverse proxy but >>>> as Jenna rightly pointed out it would spawn a lot of thin instances that >>>> might or might not be used. >>>> >>>> I did throw the sponge at Webdav on apache. It doesn't work as expected >>>> and not with all clients. It seems more suitable to store quick files than >>>> something else. >>>> Can try tomorrow with nginx but perhaps it would be nicer to have a >>>> quick camping hack to upload a file etc. but you can't just automate it >>>> entirely else you can have people running malicious code automatically... >>>> >>>> I can do the shell scripts to create virtual users for nginx and dns. >>>> Another option is to give a normal hosting for camping users. It wouldn't >>>> be an issue to have 100-200 trusted users to have access to this e.g. we >>>> can build a camping fronted for users to apply with a selection e.g. their >>>> github account, why they want the deployment hosting etc. and then once >>>> approved we would give them a normal account that would allow them to >>>> upload files on SFTP and may be even shell (which BTW is something you >>>> don't have on heroku and other services. Of course this could be protected >>>> for security or given only to active people. >>>> >>>> How does heroku screens against abuses? >>>> Anyway if some of you would like to be alpha users in this system let >>>> me know, I will be glad to set you up as soon as I am done testing >>>> subdomains etc. ;) >>>> And of course if you have a better idea for a setup let me know. >>>> >>>> Regards >>>> David >>>> >>>> >>>> >>>> >>>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >>>> >>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>>> >>>> Or you could implement webdav as an application nginx proxies to, just >>>> as it proxies to ruby instances. >>>> >>>> ? >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>>> >>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >>>> >>>> ** 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. >>>> >>>> >>>> Mh I am not really sure it would be a better performance as it would be >>>> anyway more than one process. I think that phusion passenger is pretty much >>>> the most robust solution for this. >>>> >>>> >>>> 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 >>>> >>>> >>>> Well this would be even more load as two web servers will run at the >>>> same time. Apache + Phusion passenger already lets you run .php or anything >>>> you want. >>>> >>>> But this is not the issue really. I think this is all fine in term of >>>> mono user. Question: if you have 100 users how do you configure it ? >>>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>>> >>>> >>>> But perhaps That's too much for a server ment to serve other peoples >>>> applications! Then you have to scale down the resources used. >>>> >>>> >>>> I am open to anything but if I can't do something I might ask for some >>>> brave volunteers to set it up as I really never tried anything else beside >>>> for local/quick test deployment. >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> Scarica Subito la Musica pi Trendy sul Tuo Telefonino >>>> >>>> http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> Camping-list at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> Download de gratis Registry Scan om het problem te vinden! >>>> >>>> http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ >>>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> Get the best selection of names sites here. Click Here to check them out! >> >> http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/ >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 2 08:56:15 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 2 Apr 2012 10:56:15 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: I really want to know what gems do you (all out there) think quality... Maybe there's a statistics from a big gem server which ones are the most wanted. What about the versions? Applications can work differently (or not work :- ) with different versions of gems (and ruby). Will the hosting server allow to open connections to other hosts for the uploaded apps? It is also dangerous like backtick/system calls. But if it's banned, lots of gems are excluded. 2012/4/1 Isak Andersson > ** Well. Isn't it kind of possible to just hack the gem installation in > using the ruby quotes that execute code on the system. I can't type them on > the phone but I think you know what I mean. Kind of a security issue isn't > it? > > Anyways. Perhaps we could offer some Gems to pick from that we think are > quality! (rack_csrf, scrypt). > > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: >> >> I don't think we need to go as far as automatically installing gems - >> securing ruby is a pretty big challenge, but securing gcc? no way. >> >> ? >> Jenna >> >> On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: >> >> Remember that we should pretty much make a Gemfile mandatory if the user >> makes use of gems other than Camping. For example, rack_csrf. And we should >> make sure that dependencies get installed. :) >> -- >> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. >> >> Jenna Fox skrev: >> >> Hm. I know the main guy responsible for App Engine, and, well, I >> certainly wouldn't build a platform atop it - even aside from the huge >> glaring issue that to have an app which can store data persistently, you >> need to use google's proprietary database software. >> >> Heroku doesn't screen against abuse at all. Heroku is not a 'shared >> hosting' provider. Their systems use the very finest jailing techniques to >> lock the ruby process in to it's own little world. It has no writable >> filesystem and it can only read what it absolutely needs to be able to read >> to function. All data storage happens over the network on separated >> database servers. The only type of abuse they need to be weary of is people >> using their servers to do illegal things - bullying, sharing illegal >> content, that sort of thing. They deal with that the same way any provider >> does - wait till someone makes a complaint. Matz, inventor of ruby, works >> for heroku making exactly this sort of stuff work extremely well. >> >> Still, it's not as friendly as it could be, and I personally think the >> trade offs on heroku are not very good for beginners (you have to use a >> complex database system, and cannot use the filesystem to store anything >> but static assets). >> >> Good work getting this server up David! I'm pretty excited. It sounds >> like you're having some pretty annoying deployment issues. As it's being >> quite a hassle, perhaps we should be thinking more deeply about creating >> our own special server for this task - something like the modified unicorn >> I mentioned earlier somewhere. >> >> ? >> Jenna >> >> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: >> >> Wonder if Google might help getting camping to run on app engine? >> >> On 1 April 2012 10:03, david costa wrote: >> >> Ah I forgot >> you can compare camping running on thin here >> http://run.camping.io:3301/ >> vs passenger at http://run.camping.io >> >> apparently db has some problems with fusion passenger (see >> http://run.camping.io create HTML page and test HTML page. The same code >> on thin works just fine... umhh oh no don't feel like more debugging ): >> >> >> >> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote: >> >> Okay :D after many many hours of testing I am settled for nginx and >> passenger. >> live at http://run.camping.io/ >> >> I did try every apache combination (with passenger, with cgi, etc. etc.) >> as is simply not really working fine. >> I tried some other obscure web servers too but apparently this seems to >> work fine for now :) other servers would run the app as CGI or FastCGI. I >> am not worried about speed just ease of deployment and nginx with passenger >> seems to do the job for now. The alternative is nginx as reverse proxy but >> as Jenna rightly pointed out it would spawn a lot of thin instances that >> might or might not be used. >> >> I did throw the sponge at Webdav on apache. It doesn't work as expected >> and not with all clients. It seems more suitable to store quick files than >> something else. >> Can try tomorrow with nginx but perhaps it would be nicer to have a quick >> camping hack to upload a file etc. but you can't just automate it entirely >> else you can have people running malicious code automatically... >> >> I can do the shell scripts to create virtual users for nginx and dns. >> Another option is to give a normal hosting for camping users. It wouldn't >> be an issue to have 100-200 trusted users to have access to this e.g. we >> can build a camping fronted for users to apply with a selection e.g. their >> github account, why they want the deployment hosting etc. and then once >> approved we would give them a normal account that would allow them to >> upload files on SFTP and may be even shell (which BTW is something you >> don't have on heroku and other services. Of course this could be protected >> for security or given only to active people. >> >> How does heroku screens against abuses? >> Anyway if some of you would like to be alpha users in this system let me >> know, I will be glad to set you up as soon as I am done testing subdomains >> etc. ;) >> And of course if you have a better idea for a setup let me know. >> >> Regards >> David >> >> >> >> >> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox wrote: >> >> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >> >> Or you could implement webdav as an application nginx proxies to, just as >> it proxies to ruby instances. >> >> ? >> Jenna >> >> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >> >> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote: >> >> ** 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. >> >> >> Mh I am not really sure it would be a better performance as it would be >> anyway more than one process. I think that phusion passenger is pretty much >> the most robust solution for this. >> >> >> 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 >> >> >> Well this would be even more load as two web servers will run at the same >> time. Apache + Phusion passenger already lets you run .php or anything you >> want. >> >> But this is not the issue really. I think this is all fine in term of >> mono user. Question: if you have 100 users how do you configure it ? >> How can you add webdav support on the top of the Nginx + unicorn setup ? >> >> >> But perhaps That's too much for a server ment to serve other peoples >> applications! Then you have to scale down the resources used. >> >> >> I am open to anything but if I can't do something I might ask for some >> brave volunteers to set it up as I really never tried anything else beside >> for local/quick test deployment. >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Scarica Subito la Musica pi Trendy sul Tuo Telefonino >> >> http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Download de gratis Registry Scan om het problem te vinden! >> >> http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 2 09:08:14 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 2 Apr 2012 11:08:14 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: <0A755DC3-5F99-447B-B8DA-58AE009EA142@creativepony.com> References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <0A755DC3-5F99-447B-B8DA-58AE009EA142@creativepony.com> Message-ID: > > On fastcgi - fastcgi is not a server in itself - you cannot connect to it > with a web browser. Like Passenger, it's a way for a server like nginx or > apache to launch and talk to processes which return webpages directly. > FastCGI IS a server in itself - you can connect to it, but not with a web browser. It's because it uses a protocol called fastcgi, not http. (The easiest way to interact with it is to use the cgi-fcgi command from command line...) It is not necessary to use the webserver to launch the fcgi processes, they can be configured just to connect to these servers, and you can run them whatever way you want. (I use simple init scripts for this purpose, but in a specialized hosting environment you must build a launcher for them, that handles new uploads, handles broken scripts (those that die after starting), and this system has to manage with ports associated with users, like in the case of using thin and reverse proxies.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Apr 2 09:42:34 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 2 Apr 2012 10:42:34 +0100 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: <33805FA8-027F-4AD6-8EC5-461D16764F66@innotts.co.uk> Apart from the obvious (rack, markaby, etc...), possibly trivial relevant gems I've used/tried (and am happy with): data_mapper, kramdown, RedCloth Agreed: `camping-fly MyLovelyApp` is the baseline aim - this functionality would be a deployment holy grail :-) - DaveE > I really want to know what gems do you (all out there) think > quality... > >> My idea was just to make easier for learners to run and deploy a >> camping app e.g. from command line camping-fly BestApp -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Apr 2 09:50:28 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 2 Apr 2012 10:50:28 +0100 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: A way to check for this kind of abuse would be to only allow static files referred to in the Camping app itself - DaveE > This is not an issue in terms of capacity but more security in the > sense of users being then able to run anything on their space by > uploading on sftp. It could be even used to store unwanted files etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Apr 2 14:07:39 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 2 Apr 2012 15:07:39 +0100 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: <0125184E-9F5E-4762-BA8A-BDF666780853@innotts.co.uk> haha! Oh well... you're right :-) Just emailed David to test all this with one of my totally boring little local apps. - DaveE > Oh gods not RVM. This setup does not need another layer of complexity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 2 18:05:14 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 2 Apr 2012 20:05:14 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <28FF1208-17B1-43E4-A7E9-6773EA53F5AE@creativepony.com> <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <0A755DC3-5F99-447B-B8DA-58AE009EA142@creativepony.com> Message-ID: Yes thanks for this well I am pretty set with nginx + passenger. Once I spent the week end digging into it I am pretty happy and it is the recommended way to deploy by many so I will trust this setup for now. I like this more than moving parts with reverse proxies and since it will end up to me to manage this I want to keep it simple as time is scarce ;) On Mon, Apr 2, 2012 at 11:08 AM, Nokan Emiro wrote: > On fastcgi - fastcgi is not a server in itself - you cannot connect to it >> with a web browser. Like Passenger, it's a way for a server like nginx or >> apache to launch and talk to processes which return webpages directly. >> > > FastCGI IS a server in itself - you can connect to it, but not with a web > browser. It's because it uses a protocol called fastcgi, not http. (The > easiest way to interact with it is to use the cgi-fcgi command from command > line...) It is not necessary to use the webserver to launch the fcgi > processes, they can be configured just to connect to these servers, and you > can run them whatever way you want. (I use simple init scripts for this > purpose, but in a specialized hosting environment you must build a launcher > for them, that handles new uploads, handles broken scripts (those that die > after starting), and this system has to manage with ports associated with > users, like in the case of using thin and reverse proxies.) > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 2 18:06:00 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 2 Apr 2012 20:06:00 +0200 Subject: dead easy deployment / Camping on the fly In-Reply-To: <0125184E-9F5E-4762-BA8A-BDF666780853@innotts.co.uk> References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> <0125184E-9F5E-4762-BA8A-BDF666780853@innotts.co.uk> Message-ID: > > > Just emailed David to test all this with one of my totally boring little > local apps. > > your account has been setup and details sent directly :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Apr 3 09:07:31 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 03 Apr 2012 11:07:31 +0200 Subject: Update book Message-ID: <4F7ABDD3.6000706@lavabit.com> Hello. I think we should update the book a little bit. On the part of migrations we use "def self.up" and "def self.down" this method actually gave me errors for some reason. But anyways, it should be updated to "def self.change" anyways because that's the modern way of doing it. I tried doing this myself but for some reason I don't get the gh-pages branch when cloning camping.io so Jenna or someone will have to do it instead! - Isak Andersson From a at creativepony.com Tue Apr 3 09:37:50 2012 From: a at creativepony.com (Jenna Fox) Date: Tue, 3 Apr 2012 19:37:50 +1000 Subject: Update book In-Reply-To: <4F7ABDD3.6000706@lavabit.com> References: <4F7ABDD3.6000706@lavabit.com> Message-ID: <9BDB9444A16944C892FD0D8EC64B7161@creativepony.com> Let me know exactly what text you want replaced with exactly what, and I'll make that change now. ? Jenna On Tuesday, 3 April 2012 at 7:07 PM, Isak Andersson wrote: > Hello. > > I think we should update the book a little bit. On the part of > migrations we use "def self.up" and "def self.down" this method actually > gave me errors for some reason. But anyways, it should be updated to > "def self.change" anyways because that's the modern way of doing it. > > I tried doing this myself but for some reason I don't get the gh-pages > branch when cloning camping.io (http://camping.io) so > Jenna or someone will have to do it instead! > > - Isak Andersson > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Tue Apr 3 23:00:20 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 4 Apr 2012 00:00:20 +0100 Subject: dead easy deployment / Camping on the fly In-Reply-To: References: <99B80E0C4B3644C3BEF6BF294095C992@creativepony.com> <178DD24E5D8A44EFB660C657FEFEBBAD@creativepony.com> <06ee311d-2001-4a3a-9215-810bc9aa4d47@email.android.com> <5e8d3e44-f95c-4988-84f0-1f664f894838@email.android.com> Message-ID: Been trying the setup (okay, this is not going to win any awards, but...): http://dave.camping.sh/ It's an old app rewritten (except - as yet - for the content :-) DaveE From uzleepito at gmail.com Fri Apr 6 13:01:32 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Fri, 6 Apr 2012 15:01:32 +0200 Subject: http_referrer Message-ID: Hi, How can I access the Rack request object in a controller? I need to know the HTTP_REFERRER, but I can't find it in env. (I'm sure I need glasses, or have to sleep more...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Fri Apr 6 14:27:51 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Fri, 6 Apr 2012 16:27:51 +0200 Subject: http_referrer In-Reply-To: References: Message-ID: I'm sorry bothering you, it was there in env, env['HTTP_REFERER']. (But it still would be useful sometimes to access the Rack's Request object...) On Fri, Apr 6, 2012 at 3:01 PM, Nokan Emiro wrote: > Hi, > > How can I access the Rack request object in a controller? I need > to know the HTTP_REFERRER, but I can't find it in env. (I'm > sure I need glasses, or have to sleep more...) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Fri Apr 6 14:26:23 2012 From: judofyr at gmail.com (Magnus Holm) Date: Fri, 6 Apr 2012 16:26:23 +0200 Subject: http_referrer In-Reply-To: References: Message-ID: It should be in @env: @env['HTTP_REFERER'] (Note that it's misspelled in the spec) // Magnus Holm On Friday 6. April 2012 at 15:01, Nokan Emiro wrote: > Hi, > > How can I access the Rack request object in a controller? I need > to know the HTTP_REFERRER, but I can't find it in env. (I'm > sure I need glasses, or have to sleep more...) > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list From judofyr at gmail.com Fri Apr 6 14:37:15 2012 From: judofyr at gmail.com (Magnus Holm) Date: Fri, 6 Apr 2012 16:37:15 +0200 Subject: http_referrer In-Reply-To: References: Message-ID: <2CA0BA00B1BC40DCAF94648872F9AA8E@gmail.com> Try @request. // Magnus Holm On Friday 6. April 2012 at 16:27, Nokan Emiro wrote: > I'm sorry bothering you, it was there in env, env['HTTP_REFERER']. > > (But it still would be useful sometimes to access the Rack's Request object...) > > > > On Fri, Apr 6, 2012 at 3:01 PM, Nokan Emiro wrote: > > Hi, > > > > How can I access the Rack request object in a controller? I need > > to know the HTTP_REFERRER, but I can't find it in env. (I'm > > sure I need glasses, or have to sleep more...) > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list From gurugeekphp at gmail.com Fri Apr 6 15:26:58 2012 From: gurugeekphp at gmail.com (david costa) Date: Fri, 6 Apr 2012 17:26:58 +0200 Subject: lighttpd + fastcgi + camping Message-ID: Hello all, I am running in some little stumbling blocks with passenger as a multi user environment (the most problematic feature is that, once you setup a sub-domain passenger wants you to declare on nginx every app running on that nginx server which is not ideal to add apps on the fly and / or if a user wants to run 2 apps from his space) so I was thinking about a more drag a drop / one line command line deploy (even multiple camping apps and not just one) and I would like to test camping with lighttpd + fastcgi. I assume that this would allow a user to run as many camping application as he wants (space permitting) without having to reconfigure lighttpd each time an application is added correct? Question: on the examples I can only find a camping fcgi dispatcher for apache. Do you have any dispatcher that would work on lighttpd or should I use a generic ruby dispatcher like http://pallas.telperion.info/ruby-cgi/ ? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Fri Apr 6 22:49:03 2012 From: a at creativepony.com (Jenna Fox) Date: Sat, 7 Apr 2012 08:49:03 +1000 Subject: lighttpd + fastcgi + camping In-Reply-To: References: Message-ID: <4BC18C0463B7400DA30E022990BE1628@creativepony.com> Camping is a rack app. Check out the rack docs for info on how to mount it as any kind of server interface. ? Jenna Fox On Saturday, 7 April 2012 at 1:26 AM, david costa wrote: > Hello all, > I am running in some little stumbling blocks with passenger as a multi user environment (the most problematic feature is that, once you setup a sub-domain passenger wants you to declare on nginx every app running on that nginx server which is not ideal to add apps on the fly and / or if a user wants to run 2 apps from his space) > > so I was thinking about a more drag a drop / one line command line deploy (even multiple camping apps and not just one) and I would like to test camping with lighttpd + fastcgi. I assume that this would allow a user to run as many camping application as he wants (space permitting) without having to reconfigure lighttpd each time an application is added correct? > > Question: on the examples I can only find a camping fcgi dispatcher for apache. Do you have any dispatcher that would work on lighttpd or should I use a generic ruby dispatcher like http://pallas.telperion.info/ruby-cgi/ > > ? > Thanks > David > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Sat Apr 7 16:06:36 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Sat, 7 Apr 2012 18:06:36 +0200 Subject: http_referrer In-Reply-To: References: Message-ID: Why does it work without the @ for me? On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm wrote: > It should be in @env: > > @env['HTTP_REFERER'] > > (Note that it's misspelled in the spec) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Sat Apr 7 16:11:28 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Sat, 7 Apr 2012 18:11:28 +0200 Subject: ~ AppController Message-ID: Hi, What's the nice and preferred way to run a snippet of controller code before all other normal controllers can do something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Sat Apr 7 20:42:43 2012 From: judofyr at gmail.com (Magnus Holm) Date: Sat, 7 Apr 2012 22:42:43 +0200 Subject: ~ AppController In-Reply-To: References: Message-ID: You can override #service: module App def service(*args) p({:controller => self.class, :method => @method, :args => args}) p :before super ensure p :after end end // Magnus Holm On Sat, Apr 7, 2012 at 18:11, Nokan Emiro wrote: > Hi, > > What's the nice and preferred way to run a snippet of controller code > before?all other normal controllers can do something? > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From uzleepito at gmail.com Sun Apr 8 18:50:50 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Sun, 8 Apr 2012 20:50:50 +0200 Subject: http_referrer In-Reply-To: References: Message-ID: Starship Enterprise, Stardate #{Time.now.to_f}. Captain's Log. network.http.sendrefererheader was set to 0 in my Firefox for unknown reasons. Probably Mr Spock, the Chief of security did this. I make this log entry for those who don't want to spend hours in a spacedock repairing a working application. Signing out... On Sat, Apr 7, 2012 at 6:06 PM, Nokan Emiro wrote: > Why does it work without the @ for me? > > > On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm wrote: > >> It should be in @env: >> >> @env['HTTP_REFERER'] >> >> (Note that it's misspelled in the spec) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Wed Apr 11 11:37:31 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Wed, 11 Apr 2012 13:37:31 +0200 Subject: sites powered by Camping Message-ID: Hi List, What about creating a section on the Camping site, where you list and link sites that were built using Camping? Of course just those ones that are good enough. It would show the public that it's a working framework, so it's good for the community. On the other hand it's good for the linked page too, it gets visitors and a bit boost of page rank. u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Wed Apr 11 11:55:52 2012 From: a at creativepony.com (Jenna Fox) Date: Wed, 11 Apr 2012 21:55:52 +1000 Subject: sites powered by Camping In-Reply-To: References: Message-ID: <70153F8F830646F09A2C685BDDE36524@creativepony.com> I don't think we should ever consider pagerank in decision making. Sounds like a nice idea otherwise tho. Does anyone want to maintain a page like that? ? Jenna Fox On Wednesday, 11 April 2012 at 9:37 PM, Nokan Emiro wrote: > Hi List, > > What about creating a section on the Camping site, where you list > and link sites that were built using Camping? Of course just those > ones that are good enough. It would show the public that it's a > working framework, so it's good for the community. On the other > hand it's good for the linked page too, it gets visitors and a bit boost > of page rank. > > u. > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Wed Apr 11 12:13:00 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 11 Apr 2012 13:13:00 +0100 Subject: sites powered by Camping In-Reply-To: <70153F8F830646F09A2C685BDDE36524@creativepony.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> Message-ID: <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> I've been collecting Camping links for some years, including 'sites built with', and started sorting them here (the site's not permanent, and will win precisely zero design awards - I'm also using it to test the 'Camping server' service): http://dave.camping.sh/ If anyone wants to: * send new links, * correct outdated ones with updated code (pastebin?) Please reply to this topic on the mailing list and I'll collect them temporarily on the above site. Jenna, if you point me to a file on the Camping site I'll maintain these links on it, and add the ones already on the Camping wiki. DaveE > I don't think we should ever consider pagerank in decision making. > > Sounds like a nice idea otherwise tho. Does anyone want to maintain > a page like that? > > ? > Jenna Fox > > On Wednesday, 11 April 2012 at 9:37 PM, Nokan Emiro wrote: > >> Hi List, >> >> What about creating a section on the Camping site, where you list >> and link sites that were built using Camping? Of course just those >> ones that are good enough. It would show the public that it's a >> working framework, so it's good for the community. On the other >> hand it's good for the linked page too, it gets visitors and a bit >> boost of page rank. >> >> u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Wed Apr 11 17:08:05 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Wed, 11 Apr 2012 19:08:05 +0200 Subject: sites powered by Camping In-Reply-To: <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: Hi, The tab "Sites using Camping" is empty :) I mean no more than 0 links are there. On Wed, Apr 11, 2012 at 2:13 PM, Dave Everitt wrote: > I've been collecting Camping links for some years, including 'sites built > with', and started sorting them here (the site's not permanent, and will > win precisely zero design awards - I'm also using it to test the 'Camping > server' service): > > http://dave.camping.sh/ > > If anyone wants to: > > * send new links, > * correct outdated ones with updated code (pastebin?) > > Please reply to this topic on the mailing list and I'll collect them > temporarily on the above site. > > Jenna, if you point me to a file on the Camping site I'll maintain these > links on it, and add the ones already on the Camping wiki. > > DaveE > > I don't think we should ever consider pagerank in decision making. > > Sounds like a nice idea otherwise tho. Does anyone want to maintain a page > like that? > > ? > Jenna Fox > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Wed Apr 11 22:14:48 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 11 Apr 2012 23:14:48 +0100 Subject: sites powered by Camping In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: I know. That's why it says "Look. I haven't done this yet, okay? Give me a break." :-) I spent most of the afternoon checking and tidying up the other links and the app. But they will come! I have quite a few links I haven't put up yet. Meanwhile, if you know of any, please reply to this and send them... DaveE > The tab "Sites using Camping" is empty :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Wed Apr 11 22:19:24 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 11 Apr 2012 23:19:24 +0100 Subject: sites powered by Camping In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: <25CBBCE6-500D-4E7F-B91D-451F4A8988E3@innotts.co.uk> BTW the site's repo is here so you can fork and add if you like... https://github.com/DaveEveritt/Camping-links DaveE > Hi, > > The tab "Sites using Camping" is empty :) > I mean no more than 0 links are there. > > > On Wed, Apr 11, 2012 at 2:13 PM, Dave Everitt > wrote: > I've been collecting Camping links for some years, including 'sites > built with', and started sorting them here (the site's not > permanent, and will win precisely zero design awards - I'm also > using it to test the 'Camping server' service): > > http://dave.camping.sh/ > > If anyone wants to: > > * send new links, > * correct outdated ones with updated code (pastebin?) > > Please reply to this topic on the mailing list and I'll collect them > temporarily on the above site. > > Jenna, if you point me to a file on the Camping site I'll maintain > these links on it, and add the ones already on the Camping wiki. > > DaveE > >> I don't think we should ever consider pagerank in decision making. >> >> Sounds like a nice idea otherwise tho. Does anyone want to maintain >> a page like that? >> >> ? >> Jenna Fox -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Thu Apr 12 08:17:59 2012 From: a at creativepony.com (Jenna Fox) Date: Thu, 12 Apr 2012 18:17:59 +1000 Subject: Quick site backend redo Message-ID: Looks like Judofyr isn't working on the book generator thingie, so I'll sort out a new site thing. Still sticking with caching to static files on github for now. Anyone have particular feature requests for navigational stuff and the likes? Things which would be helpful for book contributors and the likes? ? Jenna -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Thu Apr 12 11:54:08 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Thu, 12 Apr 2012 13:54:08 +0200 Subject: sites powered by Camping In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: Hi, I have been working on this in the last ~2.5 weeks: http://rapiddatingmalta.com (Yes, I know I'm slow... :- ) On Thu, Apr 12, 2012 at 12:14 AM, Dave Everitt wrote: > I know. That's why it says "Look. I haven't done this yet, okay? Give me > a break." :-) > > I spent most of the afternoon checking and tidying up the other links and > the app. But they will come! I have quite a few links I haven't put up yet. > > Meanwhile, if you know of any, please reply to this and send them... > > DaveE > > The tab "Sites using Camping" is empty :) > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Thu Apr 12 13:31:48 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Thu, 12 Apr 2012 14:31:48 +0100 Subject: sites powered by Camping In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: Hi Nokan - it's up there :-) BTW slow == good. Anyone else have a site to put up? > I have been working on this in the last ~2.5 weeks: http://rapiddatingmalta.com > (Yes, I know I'm slow... :- ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Thu Apr 12 13:35:07 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Thu, 12 Apr 2012 14:35:07 +0100 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: In another post, Jenna said: "I have some trouble with Camping's URL mapping system - so much so I'm considering sinatra for my next ruby web project" I just wanted to know what the trouble was, and if/how it might/could/ can't be addressed, so started a new thread. DaveE From a at creativepony.com Thu Apr 12 13:59:21 2012 From: a at creativepony.com (Jenna Fox) Date: Thu, 12 Apr 2012 23:59:21 +1000 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> Message-ID: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving, catchall before/after methods for controllers, and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! ? Jenna On Thursday, 12 April 2012 at 11:35 PM, Dave Everitt wrote: > In another post, Jenna said: "I have some trouble with Camping's URL > mapping system - so much so I'm considering sinatra for my next ruby > web project" > > I just wanted to know what the trouble was, and if/how it might/could/ > can't be addressed, so started a new thread. > > DaveE > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Thu Apr 12 14:26:22 2012 From: judofyr at gmail.com (Magnus Holm) Date: Thu, 12 Apr 2012 16:26:22 +0200 Subject: Camping's URL mapping system In-Reply-To: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: On Thu, Apr 12, 2012 at 15:59, Jenna Fox wrote: > The problem is basically this: > > Sometimes you want to reference static files, and other components of your > site. I have a Gallery app mounted at http://creativepony.com/gallery/ and > it causes me all sorts of trouble. Often times to reference static files I > end up needing to use /../ in URLs inside of views and controllers, which > webservers surprisingly correctly translate in to the wanted files, most of > the time. Other times I want to reference other camping apps?mounted in the > same server instance via a rack URLMap. > > I know as I say this someone will paste a function I can redefine with some > boggling ultracompressed camping code inside, where every variable is a > letter - but I have work arounds which work. The trouble is that hacking > about like this just isn't fun. > > In my opinion Camping needs in it's core?static file serving bin/camping should serve public/ > , catchall before/after methods for controllers, module App def service(*) p :before super ensure p :after end end > and I have no idea how, but we need to > fix the insanity which is the (self / arg) thing being applied to all src > and href values in markaby templates. It's a great idea and I love it when > it works, but it's so often a leaky abstraction for me, and when it leaks, > there's no clear solution! I agree, although I don't have any elegant solutions? From a at creativepony.com Thu Apr 12 14:54:51 2012 From: a at creativepony.com (Jenna Fox) Date: Fri, 13 Apr 2012 00:54:51 +1000 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: bin/camping is great but it's not usually a good way to deploy an app on a server - it tends to be more for development. Putting functionality in to bin/camping which belongs in camping core is like wearing a backpack filled with hydrogen while having your weight checked. 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. I think we should have a little line you write right in to your app file which says where you keep your files. Something like MyApp.files = 'public'. Maybe that's the default. 'just redefine service' isn't a good solution no matter how many times you post it on this list. I shouldn't need to lookup any references or archaic mailing list archives to do something so simple in a new project. For the local file urls thing, I propose a breaking change (eg: camping 3.0) the addition of a method named local() # for now it looks like this: def local arg self / arg end and the removal of magic (self / arg)ification of href and src attributes in markaby templates. local() should eventually talk to MyApp.files and the file serving feature so they can all work together nicely - all the code for that should be in one place, maybe in one class. Using local() adds some interesting opportunities too. It'd be really easy to modify local do to other stuff, like load your files from a database, or make urls which reference files by their inode number instead of their file path, or have it return data uris, or have it generate Amazon S3 urls with one time keys in them, or include the file's mtime in the url, allowing the server to specify month-long cache durations while apps instantly pick up changes, making them feel super responsive. One more thought - on file serving, I think it'd be nice if the default was that local files are served out of /files/ url rather than just being at the app's root level. I know this would be controversial: It would be really clear to beginners, and if someone writes img(src: 'files/blah.png') camping can raise a warning explaining the img(src: local 'blah.png') syntax. It also means web servers would need to be explicitly configured to duplicate that behaviour at a lower level - a simple quick camping setup would always serve files through camping, making debugging easier and applications more reliably portable. People who need the performance boost of doing it at the web server level can do that - it just wont happen by default. Deployment is one of the biggest hassles we face - this may help. ? Jenna On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: > On Thu, Apr 12, 2012 at 15:59, Jenna Fox wrote: > > The problem is basically this: > > > > Sometimes you want to reference static files, and other components of your > > site. I have a Gallery app mounted at http://creativepony.com/gallery/ and > > it causes me all sorts of trouble. Often times to reference static files I > > end up needing to use /../ in URLs inside of views and controllers, which > > webservers surprisingly correctly translate in to the wanted files, most of > > the time. Other times I want to reference other camping apps mounted in the > > same server instance via a rack URLMap. > > > > I know as I say this someone will paste a function I can redefine with some > > boggling ultracompressed camping code inside, where every variable is a > > letter - but I have work arounds which work. The trouble is that hacking > > about like this just isn't fun. > > > > In my opinion Camping needs in it's core static file serving > > bin/camping should serve public/ > > > , catchall before/after methods for controllers, > > module App > def service(*) > p :before > super > ensure > p :after > end > end > > > and I have no idea how, but we need to > > fix the insanity which is the (self / arg) thing being applied to all src > > and href values in markaby templates. It's a great idea and I love it when > > it works, but it's so often a leaky abstraction for me, and when it leaks, > > there's no clear solution! > > > > > I agree, although I don't have any elegant solutions? > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Fri Apr 13 13:44:50 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Fri, 13 Apr 2012 14:44:50 +0100 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <02941CB8-A370-43E1-BC25-CC4F56E6DFF9@innotts.co.uk> Do you mean this kind of issue: http://stackoverflow.com/questions/3755898/campings-url-doesnt-give-me-site-root-as-expected ? DaveE > One more thought - on file serving, I think it'd be nice if the > default was that local files are served out of /files/ url rather > than just being at the app's root level. I know this would be > controversial: It would be really clear to beginners, and if someone > writes img(src: 'files/blah.png') camping can raise a warning > explaining the img(src: local 'blah.png') syntax. It also means web > servers would need to be explicitly configured to duplicate that > behaviour at a lower level - a simple quick camping setup would > always serve files through camping, making debugging easier and > applications more reliably portable. People who need the performance > boost of doing it at the web server level can do that - it just wont > happen by default. Deployment is one of the biggest hassles we face > - this may help. From deveritt at innotts.co.uk Fri Apr 13 15:09:22 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Fri, 13 Apr 2012 16:09:22 +0100 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE > 3kb is great and all, but it seems kind of dishonest if the > framework isn't even really usable without a bunch of other gems and > files and stuff. The conflict between 3/4kb and having robust well > designed features often seems to haunt this project. Maybe time for > a forking? I have next to no interest in 3kb as a real feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Fri Apr 13 15:40:51 2012 From: a at creativepony.com (Jenna Fox) Date: Sat, 14 Apr 2012 01:40:51 +1000 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi ? Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: > There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE > > > 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Fri Apr 13 15:49:44 2012 From: a at creativepony.com (Jenna Fox) Date: Sat, 14 Apr 2012 01:49:44 +1000 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <04B7338387CB4B23B517214426D79455@creativepony.com> On the other hand, Camping is already far too big to fit entirely in a QR code. It would take as many as TWO QR codes to store camping in it's entirety. ? Jenna On Saturday, 14 April 2012 at 1:40 AM, Jenna Fox wrote: > An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi > > ? > Jenna > > > On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: > > > There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE > > > > > 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Fri Apr 13 15:55:05 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Fri, 13 Apr 2012 17:55:05 +0200 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Fri Apr 13 16:44:14 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Fri, 13 Apr 2012 17:44:14 +0100 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <276DC237-CF26-499E-A8E1-82C846468C30@innotts.co.uk> For me, this also depends on what Magnus - as the main Camper ninja - thinks - DaveE > I agree, I'd like to see the way Camping works to grow in to > something much more usable. Perhaps a fork is a good idea because > the legacy would remain and all. But then in the fork we could deal > with things that might be kind of annoying at times. And grow it > with a steady pace. > > If we'd fork camping I think we should still stay as minimalistic as > possible. Only adding the best things. And work on making it easy to > extend. > > Cheers! > > Isak Andersson > > Dave Everitt skrev: > There's a crucial point here... if 3k (the old 4k) is a 'proof of > concept' and a great exercise in programming skill, it isn't > something that most users will really worry about. If the 3k limit > has to be broken back up to 4 or even 5k to get some added/altered/ > optional functionality that would help usability for the rest of us, > it's not an issue for me - DaveE > >> 3kb is great and all, but it seems kind of dishonest if the >> framework isn't even really usable without a bunch of other gems >> and files and stuff. The conflict between 3/4kb and having robust >> well designed features often seems to haunt this project. Maybe >> time for a forking? I have next to no interest in 3kb as a real >> feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Fri Apr 13 18:35:02 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Fri, 13 Apr 2012 20:35:02 +0200 Subject: Camping's URL mapping system In-Reply-To: <276DC237-CF26-499E-A8E1-82C846468C30@innotts.co.uk> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <276DC237-CF26-499E-A8E1-82C846468C30@innotts.co.uk> Message-ID: <9a62c298-1583-46da-9a4a-a9800aee15a1@email.android.com> Yeah of course! Cheers! Isak Andersson Dave Everitt skrev: For me, this also depends on what Magnus - as the main Camper ninja - thinks - DaveE I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Choose the Prize you Want to Win, Play PacMan to it! http://click.lavabit.com/ww7o34bkc7cxdk49gqcbw6x8jgi7jrtao1g6b4swpcrtko5bz8uy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Fri Apr 13 19:37:52 2012 From: judofyr at gmail.com (Magnus Holm) Date: Fri, 13 Apr 2012 21:37:52 +0200 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: On Thu, Apr 12, 2012 at 16:54, Jenna Fox wrote: > bin/camping is great but it's not usually a good way to deploy an app on a > server - it tends to be more for development. Yes, and when you're deploying there are better ways to serve static files. > Putting functionality in to > bin/camping which belongs in camping core is like wearing a backpack filled > with hydrogen while having your weight checked. 3kb is great and all, but it > seems kind of dishonest if the framework isn't even really usable without a > bunch of other gems and files and stuff. The conflict between 3/4kb and > having robust well designed features often seems to haunt this project. > Maybe time for a forking? I have next to no interest in 3kb as a real > feature. > > I think we should have a little line you write right in to your app file > which says where you keep your files. Something like MyApp.files = 'public'. > Maybe that's the default. > > 'just redefine service' isn't a good solution no matter how many times you > post it on this list. I shouldn't need to lookup any references or archaic > mailing list archives to do something so simple in a new project. What about something like this: module App::Controllers class Index def before p "before #{@method}" super end def after super p "after #{@method}" end end end They can also be overridden at app-level: module App def before; ? end def after; ? end end It's probably 40 more bytes. > For the local file urls thing, I propose a breaking change (eg: camping 3.0) > > the addition of a method named local() > > # for now it looks like this: > def local arg > ? self / arg > end > > and the removal of magic (self / arg)ification of href and src attributes in > markaby templates. That doesn't seem like an optimal solution either. That means that I can develop an app like this: def view a "Hello", :href => R(Hello) end And it works great in development, but deploying on a sub-path is going to be a pain because I need to wrap everything in local(). I'm really not sure if there's a good solution here. Right now Camping optimizes for local URLs which seems more useful than optimizing for external URLs? There are ways to make it work correctly in both cases, but they are kinda ugly/magic. R(Hello) can return an instance of a subclass of String and `self/` will only expand the string if it is_a?(Internal). Again: I'm not sure what the best solution is :-( > local() should eventually talk to MyApp.files and the file serving feature > so they can all work together nicely - all the code for that should be in > one place, maybe in one class. Using local() adds some interesting > opportunities too. It'd be really easy to modify local do to other stuff, > like load your files from a database, or make urls which reference files by > their inode number instead of their file path, or have it return data uris, > or have it generate Amazon S3 urls with one time keys in them, or include > the file's mtime in the url, allowing the server to specify month-long cache > durations while apps instantly pick up changes, making them feel super > responsive. > > One more thought - on file serving, I think it'd be nice if the default was > that local files are served out of /files/ url rather than just being at the > app's root level. I know this would be controversial: It would be really > clear to beginners, and if someone writes img(src: 'files/blah.png') camping > can raise a warning explaining the img(src: local 'blah.png') syntax. It > also means web servers would need to be explicitly configured to duplicate > that behaviour at a lower level - a simple quick camping setup would always > serve files through camping, making debugging easier and applications more > reliably portable. People who need the performance boost of doing it at the > web server level can do that - it just wont happen by default. Deployment is > one of the biggest hassles we face - this may help. > > ? > Jenna > > On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: > > On Thu, Apr 12, 2012 at 15:59, Jenna Fox wrote: > > The problem is basically this: > > Sometimes you want to reference static files, and other components of your > site. I have a Gallery app mounted at http://creativepony.com/gallery/ and > it causes me all sorts of trouble. Often times to reference static files I > end up needing to use /../ in URLs inside of views and controllers, which > webservers surprisingly correctly translate in to the wanted files, most of > the time. Other times I want to reference other camping apps?mounted in the > same server instance via a rack URLMap. > > I know as I say this someone will paste a function I can redefine with some > boggling ultracompressed camping code inside, where every variable is a > letter - but I have work arounds which work. The trouble is that hacking > about like this just isn't fun. > > In my opinion Camping needs in it's core?static file serving > > > bin/camping should serve public/ > > , catchall before/after methods for controllers, > > > module App > def service(*) > p :before > super > ensure > p :after > end > end > > and I have no idea how, but we need to > fix the insanity which is the (self / arg) thing being applied to all src > and href values in markaby templates. It's a great idea and I love it when > it works, but it's so often a leaky abstraction for me, and when it leaks, > there's no clear solution! > > > I agree, although I don't have any elegant solutions? > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From a at creativepony.com Sat Apr 14 01:03:40 2012 From: a at creativepony.com (Jenna Fox) Date: Sat, 14 Apr 2012 11:03:40 +1000 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <385215A6B5D04C52893B434412094405@creativepony.com> On static files: Sure, there are ways to have a server do your static files for you, but those ways are inconsistent and require strong knowledge of servers - further, they limit Camping's ability to do smart things with cache control. As a framework which tries to be friendly to beginners, deployment is in my opinion our biggest problem today. Most people do not need the questionable performance benefits of serving static files at the reverse proxy layer. All of my camping apps serve from the app-server via crazy messy config.ru files. As a ruby person, I never want to spend time messing with web server config files if I could just do it in ruby all in the one place. On filters: Defining methods is no good - one of the primary uses of filters is authentication - something you'd want in many controllers but not all, or applying only post methods but not get sometimes. This is why being able to reference a method from helpers on a per-method level is really great. Defining a before() method on the class is also bad, because what then happens if you do a HTTP BEFORE request? Camping has always been friendly towards HTTP's support for arbitrary methods, and it'd be a shame to see that go. The cleanness of the class's methods being the http methods precisely is important to me. Being able to set and unset the before and after's as a state machine just like with private, protected, and public, I think is the best syntax for this. It's just like protecting a method you don't want web accessible. After is useful, for instance how I processed headings in the camping.io site - each heading needed to be replaced with more complex markup to handle multiple typefaces for the colours - so I do a gsub. Nokogiri would have been another great way to do it - perfect for an after filter. The way I ended up doing it was pretty messy. On self/: The current behaviour is confusing, as it is not how HTML works. In all other times when you pass a string in to markaby like that, it just uses that string as the attribute value. R(Controller) should return a relative URI::HTTP, as with local(arg) returning a relative uri to the file handler (effectively R(Files, arg)). How about we make the handling of URIs magic and leave strings as the attribute's actual unprocessed value. An absolute URI (beginning with / in path) should be pretty much just to_s'd, while a relative uri would be merged with the (self / whatever) logic. In fact, URI already is smart enough to do exactly this and also handle URIs pointing to other servers. All we need is a URI pointing to the app's root, then we just URI#merge with the argument URI. The main problem today is that when you write '/something' camping modifies it with self / '/something' and it ends up being '/app/something' - not how HTML works. The only way to reference things outside the camping app's mount point that I know of is '/../something', which camping outputs as '/app/../something', and which some web servers are happy enough to process, undoubtably with a performance hit. It just looks silly when you look at the resulting pages and their URLs, and if you're using it for links it's even worse - it could negatively affect mirroring bots by creating many URLs which point to the same file. Googlebots and the likes do not like that. There's also another opportunity here - if we make the (self / x) merge happen inside of R() and local() we can expose those to the public ruby environment and you can have say, three camping apps mounted and from your Gallery app you could call on your Guestbook's R() and local() methods somehow and get absolute urls to it's controllers, so you could do easy links between camping apps. Not sure how to make Guestbook.R(Controller) work though since the Controller is inside Guestbook::Controllers and not in the Gallery. Maybe the external syntax changes a little to R(:SignWall, 'fred'). In fact, the whole controllers being referenceable everywhere thing is a bit magical at the moment - maybe we should just deprecate the syntax and switch to symbols. Symbols syntaxically look worse. Maybe there's another way which would be nice and tidy but also not depend on shuffling references to constants all over the place. ? Jenna On Saturday, 14 April 2012 at 5:37 AM, Magnus Holm wrote: > On Thu, Apr 12, 2012 at 16:54, Jenna Fox wrote: > > bin/camping is great but it's not usually a good way to deploy an app on a > > server - it tends to be more for development. > > > > > Yes, and when you're deploying there are better ways to serve static files. > > > Putting functionality in to > > bin/camping which belongs in camping core is like wearing a backpack filled > > with hydrogen while having your weight checked. 3kb is great and all, but it > > seems kind of dishonest if the framework isn't even really usable without a > > bunch of other gems and files and stuff. The conflict between 3/4kb and > > having robust well designed features often seems to haunt this project. > > Maybe time for a forking? I have next to no interest in 3kb as a real > > feature. > > > > I think we should have a little line you write right in to your app file > > which says where you keep your files. Something like MyApp.files = 'public'. > > Maybe that's the default. > > > > 'just redefine service' isn't a good solution no matter how many times you > > post it on this list. I shouldn't need to lookup any references or archaic > > mailing list archives to do something so simple in a new project. > > > > > What about something like this: > > module App::Controllers > class Index > def before > p "before #{@method}" > super > end > > def after > super > p "after #{@method}" > end > end > end > > They can also be overridden at app-level: > > module App > def before; ? end > def after; ? end > end > > It's probably 40 more bytes. > > > For the local file urls thing, I propose a breaking change (eg: camping 3.0) > > > > the addition of a method named local() > > > > # for now it looks like this: > > def local arg > > self / arg > > end > > > > and the removal of magic (self / arg)ification of href and src attributes in > > markaby templates. > > > > > That doesn't seem like an optimal solution either. That means that I > can develop an app like this: > > def view > a "Hello", :href => R(Hello) > end > > And it works great in development, but deploying on a sub-path is > going to be a pain because I need to wrap everything in local(). > > I'm really not sure if there's a good solution here. Right now Camping > optimizes for local URLs which seems more useful than optimizing for > external URLs? > > There are ways to make it work correctly in both cases, but they are > kinda ugly/magic. R(Hello) can return an instance of a subclass of > String and `self/` will only expand the string if it is_a?(Internal). > Again: I'm not sure what the best solution is :-( > > > local() should eventually talk to MyApp.files and the file serving feature > > so they can all work together nicely - all the code for that should be in > > one place, maybe in one class. Using local() adds some interesting > > opportunities too. It'd be really easy to modify local do to other stuff, > > like load your files from a database, or make urls which reference files by > > their inode number instead of their file path, or have it return data uris, > > or have it generate Amazon S3 urls with one time keys in them, or include > > the file's mtime in the url, allowing the server to specify month-long cache > > durations while apps instantly pick up changes, making them feel super > > responsive. > > > > One more thought - on file serving, I think it'd be nice if the default was > > that local files are served out of /files/ url rather than just being at the > > app's root level. I know this would be controversial: It would be really > > clear to beginners, and if someone writes img(src: 'files/blah.png') camping > > can raise a warning explaining the img(src: local 'blah.png') syntax. It > > also means web servers would need to be explicitly configured to duplicate > > that behaviour at a lower level - a simple quick camping setup would always > > serve files through camping, making debugging easier and applications more > > reliably portable. People who need the performance boost of doing it at the > > web server level can do that - it just wont happen by default. Deployment is > > one of the biggest hassles we face - this may help. > > > > ? > > Jenna > > > > On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: > > > > On Thu, Apr 12, 2012 at 15:59, Jenna Fox wrote: > > > > The problem is basically this: > > > > Sometimes you want to reference static files, and other components of your > > site. I have a Gallery app mounted at http://creativepony.com/gallery/ and > > it causes me all sorts of trouble. Often times to reference static files I > > end up needing to use /../ in URLs inside of views and controllers, which > > webservers surprisingly correctly translate in to the wanted files, most of > > the time. Other times I want to reference other camping apps mounted in the > > same server instance via a rack URLMap. > > > > I know as I say this someone will paste a function I can redefine with some > > boggling ultracompressed camping code inside, where every variable is a > > letter - but I have work arounds which work. The trouble is that hacking > > about like this just isn't fun. > > > > In my opinion Camping needs in it's core static file serving > > > > > > bin/camping should serve public/ > > > > , catchall before/after methods for controllers, > > > > > > module App > > def service(*) > > p :before > > super > > ensure > > p :after > > end > > end > > > > and I have no idea how, but we need to > > fix the insanity which is the (self / arg) thing being applied to all src > > and href values in markaby templates. It's a great idea and I love it when > > it works, but it's so often a leaky abstraction for me, and when it leaks, > > there's no clear solution! > > > > > > I agree, although I don't have any elegant solutions? > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Sat Apr 14 08:38:10 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Sat, 14 Apr 2012 09:38:10 +0100 Subject: http_referrer In-Reply-To: References: Message-ID: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Haha! How did you get Spock on board... :-) I must admit I'm a little confused about the sytnax for environmental variables, because as well as @env[HTTP_REFERER] this also works: ENV['SCRIPT_NAME'] For a test I just used it like this: ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) to get the Camping file's name (with whatever file extension rb, rbx, cgi) instead of using __FILE__ I think I'll throw together a quick Camping app that 'nicely' prints all available environment variables (as they'll vary for each setup)... DaveE > Starship Enterprise, Stardate #{Time.now.to_f}. Captain's Log. > network.http.sendrefererheader was set to 0 in my Firefox for > unknown reasons. > Probably Mr Spock, the Chief of security did this. > I make this log entry for those who don't want to spend hours in a > spacedock repairing a working application. > Signing out... > > > On Sat, Apr 7, 2012 at 6:06 PM, Nokan Emiro > wrote: > Why does it work without the @ for me? > > > On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm wrote: > It should be in @env: > > @env['HTTP_REFERER'] > > (Note that it's misspelled in the spec) > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Sat Apr 14 10:02:17 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Sat, 14 Apr 2012 11:02:17 +0100 Subject: http_referrer In-Reply-To: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: <0E485167-6C64-460A-877B-0817F5CB59B4@innotts.co.uk> About environment variables - I've just used this in my Camping helpers to print them all out, but the Rack variables seem to have multiple values or values with no name: def envars(theenv) if theenv == "ENV" ul do theenv.each_pair do |name,value| li { name + " " + value } end end else ul do theenv.each do |name| li { name } end end end end called with: envars(ENV) envars(@env) Can some one enlighten me about how Rack env vars are stored, and how to get a nice printout? DaveE > Haha! How did you get Spock on board... :-) > > I must admit I'm a little confused about the sytnax for > environmental variables, because as well as > @env[HTTP_REFERER] > this also works: > ENV['SCRIPT_NAME'] > > For a test I just used it like this: > ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) > to get the Camping file's name (with whatever file extension rb, > rbx, cgi) instead of using __FILE__ > > I think I'll throw together a quick Camping app that 'nicely' prints > all available environment variables (as they'll vary for each > setup)... > > DaveE > >> Starship Enterprise, Stardate #{Time.now.to_f}. Captain's Log. >> network.http.sendrefererheader was set to 0 in my Firefox for >> unknown reasons. >> Probably Mr Spock, the Chief of security did this. >> I make this log entry for those who don't want to spend hours in a >> spacedock repairing a working application. >> Signing out... >> >> >> On Sat, Apr 7, 2012 at 6:06 PM, Nokan Emiro >> wrote: >> Why does it work without the @ for me? >> >> >> On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm >> wrote: >> It should be in @env: >> >> @env['HTTP_REFERER'] >> >> (Note that it's misspelled in the spec) From deveritt at innotts.co.uk Sat Apr 14 12:12:43 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Sat, 14 Apr 2012 13:12:43 +0100 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <2BF0774E-D334-455A-BB34-A4962AA9F75F@innotts.co.uk> LOL! Good to know, if I ever need to do those things :-) > An A4 piece of paper has a little over 9kb of data storage if > storing in binary at 300dpi > > On the other hand, Camping is already far too big to fit entirely in > a QR code. It would take as many as TWO QR codes to store camping in > it's entirety. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruby at monnet-usa.com Sat Apr 14 13:56:27 2012 From: ruby at monnet-usa.com (Philippe Monnet) Date: Sat, 14 Apr 2012 07:56:27 -0600 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <4F89820B.8060209@monnet-usa.com> On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. "... free free set them free ..." On 4/13/2012 9:55 AM, Isak Andersson wrote: > I agree, I'd like to see the way Camping works to grow in to something > much more usable. Perhaps a fork is a good idea because the legacy > would remain and all. But then in the fork we could deal with things > that might be kind of annoying at times. And grow it with a steady pace. > > If we'd fork camping I think we should still stay as minimalistic as > possible. Only adding the best things. And work on making it easy to > extend. > > Cheers! > > Isak Andersson > > Dave Everitt skrev: > > There's a crucial point here... if 3k (the old 4k) is a 'proof of > concept' and a great exercise in programming skill, it isn't > something that most users will really worry about. If the 3k limit > has to be broken back up to 4 or even 5k to get some > added/altered/optional functionality that would help usability for > the rest of us, it's not an issue for me - DaveE > >> 3kb is great and all, but it seems kind of dishonest if the >> framework isn't even really usable without a bunch of other gems >> and files and stuff. The conflict between 3/4kb and having robust >> well designed features often seems to haunt this project. Maybe >> time for a forking? I have next to no interest in 3kb as a real >> feature. > > Get the best selection of online sites here. Click Here to check them out! > http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From _ at whats-your.name Sat Apr 14 11:08:29 2012 From: _ at whats-your.name (cdr) Date: Sat, 14 Apr 2012 11:08:29 +0000 Subject: http_referrer In-Reply-To: <0E485167-6C64-460A-877B-0817F5CB59B4@innotts.co.uk> References: <0E485167-6C64-460A-877B-0817F5CB59B4@innotts.co.uk> Message-ID: <20120414110829.GA4767@s.clearwire-wmx.net> how Rack env vars are stored, and how to get a nice printout? i defined #to_html on everything. on Array thats map(&:html).join ', ' on Hash it prints a , Object is html_escape(to_s) Rack just iterates thru env in an ERB template:

Rack ENV

<% env.sort_by { |k, v| k.to_s }.each { |key, val| %> <% } %>
Variable Value
<%=h key %>
<%=h val %>
i wonder how small camping could become if it was a rubyish exoskeleton for plugging together Rack tidbits. 1K? From IcePapih at lavabit.com Sat Apr 14 14:46:24 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sat, 14 Apr 2012 16:46:24 +0200 Subject: framework size, forking etc. In-Reply-To: <4F89820B.8060209@monnet-usa.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> Message-ID: <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Right. We could just have a branch called "classic" on github. Leaving everything untouched. And then change the gem name to camping-classic or something. Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. Cheers! Isak Andersson Philippe Monnet skrev: On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. "... free free set them free ..." On 4/13/2012 9:55 AM, Isak Andersson wrote: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Play Your Favorite Free Games Right On Your Browser - 100% Free! http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From _ at whats-your.name Sat Apr 14 10:34:48 2012 From: _ at whats-your.name (cdr) Date: Sat, 14 Apr 2012 10:34:48 +0000 Subject: Camping's URL mapping system In-Reply-To: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <20120414103448.GA4328@s.clearwire-wmx.net> rack has a minimal file-server [0] 0. https://github.com/rack/rack/blob/6496241b25daa20fd9dd736119dc39bdac54869d/lib/rack/file.rb#L70 ive been usin it on my phone to do the basics, it kind of chokes on 128M podcasts as a mediaplayer http://repo.or.cz/w/element.git/blob_plain/HEAD:/doc/find.html it gets the job done though From gurugeekphp at gmail.com Sat Apr 14 23:59:34 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 15 Apr 2012 01:59:34 +0200 Subject: framework size, forking etc. In-Reply-To: <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: Hi all :) I have been playing with Sinatra a lot lately and perhaps *some* things are done easily there (URL mapping, static files) but being a DSL and not a framework it is a bit different. For many things camping does the job very well and overall I find it a more comprehensive solution than Sinatra. For the classic/new versions I think the issue would be if the main code maintainer (Magnus) should decide if he is willing to do that. Of course other people could do that too but it would still be two versions to maintain or, if you are freezing camping-classic as it is it should at least have a light maintenance that ensures that it would still works fine. Everyone can fork (e.g. camping-couch is a gem with couch db and no active record) the only issue is maintenance and build momentum about it ! Regards David On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: > Right. We could just have a branch called "classic" on github. Leaving > everything untouched. > > And then change the gem name to camping-classic or something. > > Maybe we should rewrite it afterwards (kind of). And make it backwards > compatible with Camping applications. Just make the infrastructure simple > and minimalistic. And make it easy to extend and configure. I think this > would be the best thing ever for Camping more or less. > > Cheers! > > Isak Andersson > > Philippe Monnet skrev: >> >> On one hand everyone is free to fork anything to change radical >> direction. This would allow for the size and some design constraints to be >> eliminated. But on the other hand, at this point in time (since we are the >> new community) shouldn't we free ourselves from the original constraints >> and just ignore the size aspect? I personally think so. It does not mean we >> have to "go crazy" and make it large and complicated (like Rails). >> With the source being on Github, we can just designate the current >> version as the "classic" (super micro version) and document very explicitly >> that from now on we will be free of these constraints and explain how >> people can still get the "classic" version. Since the framework has proven >> extremely stable and resilient, this would not prevent any tinkerer who >> needs the classic version to just do so. >> Although it has been fun to reference the size when talking about >> Camping, keeping it reasonably simple and small is good enough for me. >> >> "... free free set them free ..." >> >> On 4/13/2012 9:55 AM, Isak Andersson wrote: >> >> I agree, I'd like to see the way Camping works to grow in to something >> much more usable. Perhaps a fork is a good idea because the legacy would >> remain and all. But then in the fork we could deal with things that might >> be kind of annoying at times. And grow it with a steady pace. >> >> If we'd fork camping I think we should still stay as minimalistic as >> possible. Only adding the best things. And work on making it easy to extend. >> >> Cheers! >> >> Isak Andersson >> >> Dave Everitt skrev: >>> >>> There's a crucial point here... if 3k (the old 4k) is a 'proof of >>> concept' and a great exercise in programming skill, it isn't something that >>> most users will really worry about. If the 3k limit has to be broken back >>> up to 4 or even 5k to get some added/altered/optional functionality that >>> would help usability for the rest of us, it's not an issue for me - DaveE >>> >>> 3kb is great and all, but it seems kind of dishonest if the framework >>> isn't even really usable without a bunch of other gems and files and stuff. >>> The conflict between 3/4kb and having robust well designed features often >>> seems to haunt this project. Maybe time for a forking? I have next to no >>> interest in 3kb as a real feature. >>> >>> >>> Get the best selection of online sites here. Click Here to check them >> out! >> >> http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ >> >> >> _______________________________________________ >> Camping-list mailing listCamping-list at rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list >> >> >> Play Your Favorite Free Games Right On Your Browser - 100% Free! >> >> http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Sun Apr 15 09:16:57 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 15 Apr 2012 11:16:57 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> Ah, no I didn't mean maintaining two versions. Just making sure that everything in current Camping works as it should (not sure it does, my migrations aren't happening) and then freeze it. Call it Camping classic and then re-write it to be well designed for extensibility. With readable code and all. The names for things in our methods should be more then one character l?ng when we aren't worrying about size anymore. Cheers! Isak Andersson david costa skrev: Hi all :) I have been playing with Sinatra a lot lately and perhaps *some* things are done easily there (URL mapping, static files) but being a DSL and not a framework it is a bit different. For many things camping does the job very well and overall I find it a more comprehensive solution than Sinatra. For the classic/new versions I think the issue would be if the main code maintainer (Magnus) should decide if he is willing to do that. Of course other people could do that too but it would still be two versions to maintain or, if you are freezing camping-classic as it is it should at least have a light maintenance that ensures that it would still works fine. Everyone can fork (e.g. camping-couch is a gem with couch db and no active record) the only issue is maintenance and build momentum about it ! Regards David On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: Right. We could just have a branch called "classic" on github. Leaving everything untouched. And then change the gem name to camping-classic or something. Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. Cheers! Isak Andersson Philippe Monnet skrev: On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. "... free free set them free ..." On 4/13/2012 9:55 AM, Isak Andersson wrote: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Play Your Favorite Free Games Right On Your Browser - 100% Free! http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of cell phone sites here. Click Here to check them out! http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Sun Apr 15 10:37:23 2012 From: judofyr at gmail.com (Magnus Holm) Date: Sun, 15 Apr 2012 12:37:23 +0200 Subject: http_referrer In-Reply-To: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: On Sat, Apr 14, 2012 at 10:38, Dave Everitt wrote: > Haha! How did you get Spock on board... :-) > > I must admit I'm a little confused about the sytnax for environmental > variables, because as well as > ? @env[HTTP_REFERER] > this also works: > ? ENV['SCRIPT_NAME'] > > For a test I just used it like this: > ? ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) > to get the Camping file's name?(with whatever file extension rb, rbx, > cgi)?instead of using __FILE__ The only reason ENV['HTTP_REFERER'] works for you is that you deploy on (Fast)CGI. You should only depend on @env if you want your app to be compatible with other servers. From ruby at monnet-usa.com Sun Apr 15 19:41:34 2012 From: ruby at monnet-usa.com (Philippe Monnet) Date: Sun, 15 Apr 2012 13:41:34 -0600 Subject: Serving static files within a single app Message-ID: <4F8B246E.3050307@monnet-usa.com> [First of all I am breaking off the topic about serving static files from the "Camping's URL mapping system" thread as it is becoming too hard to follow multiple topics] One solution I have been using for a while is based on the following post (back in 2007): "Serving static files in Camping, with a single route" . I do realize that it would be great to have a generic mechanism built-into the framework itself. Maybe a couple configuration options with the basic defaults could include the root of all static content (/public, /files, /static, etc.), and basic file types to be treated as static. I think this feature would be separate from the ability to serve multiple apps (although it might need to factor that in). -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Sun Apr 15 19:57:16 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 15 Apr 2012 21:57:16 +0200 Subject: Serving static files within a single app In-Reply-To: <4F8B246E.3050307@monnet-usa.com> References: <4F8B246E.3050307@monnet-usa.com> Message-ID: Camping.goes :App module App use Rack::Static, :urls => ['/static'] end -- Matma Rex From deveritt at innotts.co.uk Sun Apr 15 21:41:20 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Sun, 15 Apr 2012 22:41:20 +0100 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: <063443CC-55C2-42BA-8340-A3E287EFBC10@innotts.co.uk> Understood about compatible - this is David's Camping server, and I'm experimenting with QUERY_STRING in the URL and various other env vars - DaveE > On Sat, Apr 14, 2012 at 10:38, Dave Everitt > wrote: >> Haha! How did you get Spock on board... :-) >> >> I must admit I'm a little confused about the sytnax for environmental >> variables, because as well as >> @env[HTTP_REFERER] >> this also works: >> ENV['SCRIPT_NAME'] >> >> For a test I just used it like this: >> ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) >> to get the Camping file's name (with whatever file extension rb, rbx, >> cgi) instead of using __FILE__ > > The only reason ENV['HTTP_REFERER'] works for you is that you deploy > on (Fast)CGI. You should only depend on @env if you want your app to > be compatible with other servers. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From gurugeekphp at gmail.com Sun Apr 15 23:40:17 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 16 Apr 2012 01:40:17 +0200 Subject: http_referrer In-Reply-To: <063443CC-55C2-42BA-8340-A3E287EFBC10@innotts.co.uk> References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <063443CC-55C2-42BA-8340-A3E287EFBC10@innotts.co.uk> Message-ID: Ah well the is not on fcgi but passenger :) I would say that most of the serious ruby/rails hosting now offer passenger as an option so shouldn't limit your application portability. On Sun, Apr 15, 2012 at 11:41 PM, Dave Everitt wrote: > Understood about compatible - this is David's Camping server, and I'm > experimenting with QUERY_STRING in the URL and various other env vars - > DaveE > > > On Sat, Apr 14, 2012 at 10:38, Dave Everitt >> wrote: >> >>> Haha! How did you get Spock on board... :-) >>> >>> I must admit I'm a little confused about the sytnax for environmental >>> variables, because as well as >>> @env[HTTP_REFERER] >>> this also works: >>> ENV['SCRIPT_NAME'] >>> >>> For a test I just used it like this: >>> ENV['SCRIPT_NAME'].scan(/\w+\.**\w+$/) >>> to get the Camping file's name (with whatever file extension rb, rbx, >>> cgi) instead of using __FILE__ >>> >> >> The only reason ENV['HTTP_REFERER'] works for you is that you deploy >> on (Fast)CGI. You should only depend on @env if you want your app to >> be compatible with other servers. >> ______________________________**_________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/**listinfo/camping-list >> > > ______________________________**_________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/**listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Mon Apr 16 00:13:27 2012 From: a at creativepony.com (Jenna Fox) Date: Mon, 16 Apr 2012 10:13:27 +1000 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <063443CC-55C2-42BA-8340-A3E287EFBC10@innotts.co.uk> Message-ID: O_o I think the extra character is worth it. ? Jenna On Monday, 16 April 2012 at 9:40 AM, david costa wrote: > Ah well the is not on fcgi but passenger :) > I would say that most of the serious ruby/rails hosting now offer passenger as an option so shouldn't limit your application portability. > > On Sun, Apr 15, 2012 at 11:41 PM, Dave Everitt wrote: > > Understood about compatible - this is David's Camping server, and I'm experimenting with QUERY_STRING in the URL and various other env vars - DaveE > > > > > > > On Sat, Apr 14, 2012 at 10:38, Dave Everitt wrote: > > > > Haha! How did you get Spock on board... :-) > > > > > > > > I must admit I'm a little confused about the sytnax for environmental > > > > variables, because as well as > > > > @env[HTTP_REFERER] > > > > this also works: > > > > ENV['SCRIPT_NAME'] > > > > > > > > For a test I just used it like this: > > > > ENV['SCRIPT_NAME'].scan(/\w+\.\w+$/) > > > > to get the Camping file's name (with whatever file extension rb, rbx, > > > > cgi) instead of using __FILE__ > > > > > > The only reason ENV['HTTP_REFERER'] works for you is that you deploy > > > on (Fast)CGI. You should only depend on @env if you want your app to > > > be compatible with other servers. > > > _______________________________________________ > > > Camping-list mailing list > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 16 00:24:53 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 16 Apr 2012 02:24:53 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <063443CC-55C2-42BA-8340-A3E287EFBC10@innotts.co.uk> Message-ID: sure I was just explaining that was not fcgi :) BTW I am making some good progress with the on the fly deployment. I have found an apparently good security solution to allow users to deploy their app without major problems and at the same time not compromise other users/the server. More testing this week. On Mon, Apr 16, 2012 at 2:13 AM, Jenna Fox wrote: > O_o > > I think the extra character is worth it. > > ? > Jenna > > On Monday, 16 April 2012 at 9:40 AM, david costa wrote: > > Ah well the is not on fcgi but passenger :) > I would say that most of the serious ruby/rails hosting now offer > passenger as an option so shouldn't limit your application portability. > > On Sun, Apr 15, 2012 at 11:41 PM, Dave Everitt wrote: > > Understood about compatible - this is David's Camping server, and I'm > experimenting with QUERY_STRING in the URL and various other env vars - > DaveE > > > On Sat, Apr 14, 2012 at 10:38, Dave Everitt > wrote: > > Haha! How did you get Spock on board... :-) > > I must admit I'm a little confused about the sytnax for environmental > variables, because as well as > @env[HTTP_REFERER] > this also works: > ENV['SCRIPT_NAME'] > > For a test I just used it like this: > ENV['SCRIPT_NAME'].scan(/\w+\.**\w+$/) > to get the Camping file's name (with whatever file extension rb, rbx, > cgi) instead of using __FILE__ > > > The only reason ENV['HTTP_REFERER'] works for you is that you deploy > on (Fast)CGI. You should only depend on @env if you want your app to > be compatible with other servers. > ______________________________**_________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/**listinfo/camping-list > > > ______________________________**_________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/**listinfo/camping-list > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 11:45:08 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 13:45:08 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: Actually env[] works with mongrel also, not just fcgi or passenger. (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) On Sun, Apr 15, 2012 at 12:37 PM, Magnus Holm wrote: > > > The only reason ENV['HTTP_REFERER'] works for you is that you deploy > on (Fast)CGI. You should only depend on @env if you want your app to > be compatible with other servers. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 12:04:59 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 14:04:59 +0200 Subject: Markaby xhtml_strict Message-ID: Hi, I use this in Markaby to generate an html tag, but I need to add lang="lc" and xml:lang="lc" (lc != :en). However xhtml_strict does not accept arguments. :-/ Why not? And then how should I generate XHTML1.0 Strict docs in other languages? (I always feel foolish when face with such trivial problems...) u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 12:17:28 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 14:17:28 +0200 Subject: framework size, forking etc. In-Reply-To: <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> Message-ID: Hi, As a simple user of Camping I would prefer to have a classic and a "modern" one. in one gem or in separate ones, that's not an issue. I would like to use the old one without modifications in my apps, and if I need extra features, I can uncomment/inser a line like this: require 'camping' require 'camping/session' # require 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' Camping.goes :MyApp module MyApp ... But it's just a feature request... u. 2012/4/15 Isak Andersson > ** Ah, no I didn't mean maintaining two versions. Just making sure that > everything in current Camping works as it should (not sure it does, my > migrations aren't happening) and then freeze it. Call it Camping classic > and then re-write it to be well designed for extensibility. With readable > code and all. The names for things in our methods should be more then one > character l?ng when we aren't worrying about size anymore. > > Cheers! > > Isak Andersson > > david costa skrev: >> >> Hi all :) >> I have been playing with Sinatra a lot lately and perhaps *some* things >> are done easily there (URL mapping, static files) but being a DSL and not a >> framework it is a bit different. For many things camping does the job very >> well and overall I find it a more comprehensive solution than Sinatra. >> >> For the classic/new versions I think the issue would be if the main code >> maintainer (Magnus) should decide if he is willing to do that. Of course >> other people could do that too but it would still be two versions to >> maintain or, if you are freezing camping-classic as it is it should at >> least have a light maintenance that ensures that it would still works fine. >> >> Everyone can fork (e.g. camping-couch is a gem with couch db and no >> active record) the only issue is maintenance and build momentum about it ! >> Regards >> David >> >> >> >> On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: >> >>> Right. We could just have a branch called "classic" on github. Leaving >>> everything untouched. >>> >>> And then change the gem name to camping-classic or something. >>> >>> Maybe we should rewrite it afterwards (kind of). And make it backwards >>> compatible with Camping applications. Just make the infrastructure simple >>> and minimalistic. And make it easy to extend and configure. I think this >>> would be the best thing ever for Camping more or less. >>> >>> Cheers! >>> >>> Isak Andersson >>> >>> Philippe Monnet skrev: >>>> >>>> On one hand everyone is free to fork anything to change radical >>>> direction. This would allow for the size and some design constraints to be >>>> eliminated. But on the other hand, at this point in time (since we are the >>>> new community) shouldn't we free ourselves from the original constraints >>>> and just ignore the size aspect? I personally think so. It does not mean we >>>> have to "go crazy" and make it large and complicated (like Rails). >>>> With the source being on Github, we can just designate the current >>>> version as the "classic" (super micro version) and document very explicitly >>>> that from now on we will be free of these constraints and explain how >>>> people can still get the "classic" version. Since the framework has proven >>>> extremely stable and resilient, this would not prevent any tinkerer who >>>> needs the classic version to just do so. >>>> Although it has been fun to reference the size when talking about >>>> Camping, keeping it reasonably simple and small is good enough for me. >>>> >>>> "... free free set them free ..." >>>> >>>> On 4/13/2012 9:55 AM, Isak Andersson wrote: >>>> >>>> I agree, I'd like to see the way Camping works to grow in to something >>>> much more usable. Perhaps a fork is a good idea because the legacy would >>>> remain and all. But then in the fork we could deal with things that might >>>> be kind of annoying at times. And grow it with a steady pace. >>>> >>>> If we'd fork camping I think we should still stay as minimalistic as >>>> possible. Only adding the best things. And work on making it easy to extend. >>>> >>>> Cheers! >>>> >>>> Isak Andersson >>>> >>>> Dave Everitt skrev: >>>>> >>>>> There's a crucial point here... if 3k (the old 4k) is a 'proof of >>>>> concept' and a great exercise in programming skill, it isn't something that >>>>> most users will really worry about. If the 3k limit has to be broken back >>>>> up to 4 or even 5k to get some added/altered/optional functionality that >>>>> would help usability for the rest of us, it's not an issue for me - DaveE >>>>> >>>>> 3kb is great and all, but it seems kind of dishonest if the framework >>>>> isn't even really usable without a bunch of other gems and files and stuff. >>>>> The conflict between 3/4kb and having robust well designed features often >>>>> seems to haunt this project. Maybe time for a forking? I have next to no >>>>> interest in 3kb as a real feature. >>>>> >>>>> >>>>> Get the best selection of online sites here. Click Here to check >>>> them out! >>>> >>>> http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing listCamping-list at rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> Play Your Favorite Free Games Right On Your Browser - 100% Free! >>>> >>>> http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ >>>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> Get the best selection of cell phone sites here. Click Here to check >> them out! >> >> http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Mon Apr 16 13:36:25 2012 From: a at creativepony.com (Jenna Fox) Date: Mon, 16 Apr 2012 23:36:25 +1000 Subject: Markaby xhtml_strict In-Reply-To: References: Message-ID: <3CA355EB48704F2BBCE9462FA3AC980A@creativepony.com> Urgh. I just turn the validation in markaby off pretty much all of the time - like strictly typed languages, I find it gets in my way more often than it helps me find errors. Instead of using the xhtml_strict macro you could do it yourself: self << "\n" html "lang" => 'lc', "xml:lang" => 'lc' do ... end Though if you're going down to this level, why not switch over to html5? Everything you can reliably do in xhtml 1.0 is also available in html5, and the html5 doctype is simpler, while still supporting browser features using the same syntaxes you're familiar with in addition to newer compact versions. The html5 doctype is this: self << "\n" HTML5 will become the default in a future edition of camping, as it supersedes the xhtml standard and provides compactness benefits and useful new features. Further, xml:lang is not necessary when using html5 syntax - lang is sufficient. Have you also considered the possibility of serving the language as a header? Content-Language is a http header of similar effect, which you could even set in your markaby templates via @headers['Content-Language'] = 'lc' ? Jenna On Monday, 16 April 2012 at 10:04 PM, Nokan Emiro wrote: > Hi, > > I use this in Markaby to generate an html tag, but I need to add lang="lc" and > xml:lang="lc" (lc != :en). However xhtml_strict does not accept arguments. :-/ > Why not? And then how should I generate XHTML1.0 Strict docs in other > languages? (I always feel foolish when face with such trivial problems...) > > u. > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Mon Apr 16 13:37:22 2012 From: a at creativepony.com (Jenna Fox) Date: Mon, 16 Apr 2012 23:37:22 +1000 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> Message-ID: <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> So the 3kb thing is pretty important to you? Anyone else feel the same way? :) ? Jenna On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: > Hi, > > As a simple user of Camping I would prefer to have a classic and > a "modern" one. in one gem or in separate ones, that's not an issue. > I would like to use the old one without modifications in my apps, and > if I need extra features, I can uncomment/inser a line like this: > > require 'camping' > require 'camping/session' > # require 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' > Camping.goes :MyApp > module MyApp > ... > > But it's just a feature request... > > u. > > > 2012/4/15 Isak Andersson > > Ah, no I didn't mean maintaining two versions. Just making sure that everything in current Camping works as it should (not sure it does, my migrations aren't happening) and then freeze it. Call it Camping classic and then re-write it to be well designed for extensibility. With readable code and all. The names for things in our methods should be more then one character l?ng when we aren't worrying about size anymore. > > > > Cheers! > > > > Isak Andersson > > > > david costa skrev: > > > Hi all :) > > > I have been playing with Sinatra a lot lately and perhaps *some* things are done easily there (URL mapping, static files) but being a DSL and not a framework it is a bit different. For many things camping does the job very well and overall I find it a more comprehensive solution than Sinatra. > > > > > > For the classic/new versions I think the issue would be if the main code maintainer (Magnus) should decide if he is willing to do that. Of course other people could do that too but it would still be two versions to maintain or, if you are freezing camping-classic as it is it should at least have a light maintenance that ensures that it would still works fine. > > > > > > Everyone can fork (e.g. camping-couch is a gem with couch db and no active record) the only issue is maintenance and build momentum about it ! > > > Regards > > > David > > > > > > > > > > > > On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: > > > > Right. We could just have a branch called "classic" on github. Leaving everything untouched. > > > > > > > > And then change the gem name to camping-classic or something. > > > > > > > > Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. > > > > > > > > Cheers! > > > > > > > > Isak Andersson > > > > > > > > Philippe Monnet skrev: > > > > > On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). > > > > > With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. > > > > > Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. > > > > > > > > > > "... free free set them free ..." > > > > > > > > > > On 4/13/2012 9:55 AM, Isak Andersson wrote: > > > > > > I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. > > > > > > > > > > > > If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. > > > > > > > > > > > > Cheers! > > > > > > > > > > > > Isak Andersson > > > > > > > > > > > > Dave Everitt (mailto:deveritt at innotts.co.uk) skrev: > > > > > > > There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE > > > > > > > > > > > > > > > 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. > > > > > > Get the best selection of online sites here. Click Here to check them out! > > > > > > http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ > > > > > > > > > > > > _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list > > > > > Play Your Favorite Free Games Right On Your Browser - 100% Free! > > > > > http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ > > > > _______________________________________________ > > > > Camping-list mailing list > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > Get the best selection of cell phone sites here. Click Here to check them out! > > > http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Apr 16 15:40:10 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 16 Apr 2012 16:40:10 +0100 Subject: framework size, forking etc. In-Reply-To: <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> Message-ID: <0C25A53C-35FC-40C0-8A3A-DE45BAEE3511@innotts.co.uk> I'm not too bothered about 3k. But I think what Nokan's saying is that he'd like Camping to remain functioning as it is so he can continue to run his apps as they're set up now, but that extra features could be added with an optional `require 'camping/new_extra_stuff`... - Nokan, is this correct? Although I've no practical idea about how this might best be achieved - DaveE > So the 3kb thing is pretty important to you? Anyone else feel the > same way? :) > > ? > Jenna > > On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: > >> Hi, >> >> As a simple user of Camping I would prefer to have a classic and >> a "modern" one. in one gem or in separate ones, that's not an issue. >> I would like to use the old one without modifications in my apps, and >> if I need extra features, I can uncomment/inser a line like this: >> >> require 'camping' >> require 'camping/session' >> # require >> 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc >> ' >> Camping.goes :MyApp >> module MyApp >> ... >> >> But it's just a feature request... >> >> u. >> >> >> 2012/4/15 Isak Andersson >>> Ah, no I didn't mean maintaining two versions. Just making sure >>> that everything in current Camping works as it should (not sure it >>> does, my migrations aren't happening) and then freeze it. Call it >>> Camping classic and then re-write it to be well designed for >>> extensibility. With readable code and all. The names for things in >>> our methods should be more then one character l?ng when we aren't >>> worrying about size anymore. >>> >>> Cheers! >>> >>> Isak Andersson >>> >>> david costa skrev: >>>> >>>> Hi all :) >>>> I have been playing with Sinatra a lot lately and perhaps *some* >>>> things are done easily there (URL mapping, static files) but >>>> being a DSL and not a framework it is a bit different. For many >>>> things camping does the job very well and overall I find it a >>>> more comprehensive solution than Sinatra. >>>> >>>> For the classic/new versions I think the issue would be if the >>>> main code maintainer (Magnus) should decide if he is willing to >>>> do that. Of course other people could do that too but it would >>>> still be two versions to maintain or, if you are freezing camping- >>>> classic as it is it should at least have a light maintenance that >>>> ensures that it would still works fine. >>>> >>>> Everyone can fork (e.g. camping-couch is a gem with couch db and >>>> no active record) the only issue is maintenance and build >>>> momentum about it ! >>>> Regards >>>> David >>>> >>>> >>>> >>>> On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson >>> > wrote: >>>>> Right. We could just have a branch called "classic" on github. >>>>> Leaving everything untouched. >>>>> >>>>> And then change the gem name to camping-classic or something. >>>>> >>>>> Maybe we should rewrite it afterwards (kind of). And make it >>>>> backwards compatible with Camping applications. Just make the >>>>> infrastructure simple and minimalistic. And make it easy to >>>>> extend and configure. I think this would be the best thing ever >>>>> for Camping more or less. >>>>> >>>>> Cheers! >>>>> >>>>> Isak Andersson >>>>> >>>>> Philippe Monnet skrev: >>>>>> >>>>>> On one hand everyone is free to fork anything to change radical >>>>>> direction. This would allow for the size and some design >>>>>> constraints to be eliminated. But on the other hand, at this >>>>>> point in time (since we are the new community) shouldn't we >>>>>> free ourselves from the original constraints and just ignore >>>>>> the size aspect? I personally think so. It does not mean we >>>>>> have to "go crazy" and make it large and complicated (like >>>>>> Rails). >>>>>> With the source being on Github, we can just designate the >>>>>> current version as the "classic" (super micro version) and >>>>>> document very explicitly that from now on we will be free of >>>>>> these constraints and explain how people can still get the >>>>>> "classic" version. Since the framework has proven extremely >>>>>> stable and resilient, this would not prevent any tinkerer who >>>>>> needs the classic version to just do so. >>>>>> Although it has been fun to reference the size when talking >>>>>> about Camping, keeping it reasonably simple and small is good >>>>>> enough for me. >>>>>> >>>>>> "... free free set them free ..." >>>>>> >>>>>> On 4/13/2012 9:55 AM, Isak Andersson wrote: >>>>>>> >>>>>>> I agree, I'd like to see the way Camping works to grow in to >>>>>>> something much more usable. Perhaps a fork is a good idea >>>>>>> because the legacy would remain and all. But then in the fork >>>>>>> we could deal with things that might be kind of annoying at >>>>>>> times. And grow it with a steady pace. >>>>>>> >>>>>>> If we'd fork camping I think we should still stay as >>>>>>> minimalistic as possible. Only adding the best things. And >>>>>>> work on making it easy to extend. >>>>>>> >>>>>>> Cheers! >>>>>>> >>>>>>> Isak Andersson >>>>>>> >>>>>>> Dave Everitt skrev: >>>>>>>> >>>>>>>> There's a crucial point here... if 3k (the old 4k) is a >>>>>>>> 'proof of concept' and a great exercise in programming skill, >>>>>>>> it isn't something that most users will really worry about. >>>>>>>> If the 3k limit has to be broken back up to 4 or even 5k to >>>>>>>> get some added/altered/optional functionality that would help >>>>>>>> usability for the rest of us, it's not an issue for me - DaveE >>>>>>>> >>>>>>>>> 3kb is great and all, but it seems kind of dishonest if the >>>>>>>>> framework isn't even really usable without a bunch of other >>>>>>>>> gems and files and stuff. The conflict between 3/4kb and >>>>>>>>> having robust well designed features often seems to haunt >>>>>>>>> this project. Maybe time for a forking? I have next to no >>>>>>>>> interest in 3kb as a real feature. >>>>>>>> >>>>>>> >>>>>>> Get the best selection of online sites here. Click Here to >>>>>>> check them out! >>>>>>> http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Camping-list mailing list >>>>>>> Camping-list at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/camping-list >>>>>> >>>>>> Play Your Favorite Free Games Right On Your Browser - 100% Free! >>>>>> http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ >>>>> >>>>> _______________________________________________ >>>>> Camping-list mailing list >>>>> Camping-list at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> Get the best selection of cell phone sites here. Click Here to >>>> check them out! >>>> http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 15:45:53 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 17:45:53 +0200 Subject: Markaby xhtml_strict In-Reply-To: <3CA355EB48704F2BBCE9462FA3AC980A@creativepony.com> References: <3CA355EB48704F2BBCE9462FA3AC980A@creativepony.com> Message-ID: Hi, I do exactly this at the moment. I mean the Content-language HTTP header line. The problem with this is that Google can't make difference in this way between the pages in different languages - probably because of these translations are available under the same URL, and there's nothing in the document that describes the language. What's more xhtml_strict always tells that it's in English. :( Wise SEO people use a language code somewhere (in the path or as a subdomain, sometimes as a separate domain), but I don't want to go so far. I just hope that Google is good enough to recognize the different translations of the same content available under the same URL if there's something in the document that indicates this. At least a . I would like to switch to HTML5, but I'm waiting for Camping to make it the default :) u. On Mon, Apr 16, 2012 at 3:36 PM, Jenna Fox wrote: > Urgh. I just turn the validation in markaby off pretty much all of the > time - like strictly typed languages, I find it gets in my way more often > than it helps me find errors. > > Instead of using the xhtml_strict macro you could do it yourself: > > self << "\n" > html "lang" => 'lc', "xml:lang" => 'lc' do > ... > end > > Though if you're going down to this level, why not switch over to html5? > Everything you can reliably do in xhtml 1.0 is also available in html5, and > the html5 doctype is simpler, while still supporting browser features using > the same syntaxes you're familiar with in addition to newer compact > versions. The html5 doctype is this: > > self << "\n" > > HTML5 will become the default in a future edition of camping, as it > supersedes the xhtml standard and provides compactness benefits and useful > new features. Further, xml:lang is not necessary when using html5 syntax - > lang is sufficient. > > Have you also considered the possibility of serving the language as a > header? Content-Language is a http header of similar effect, which you > could even set in your markaby templates via @headers['Content-Language'] = > 'lc' > > ? > Jenna > > On Monday, 16 April 2012 at 10:04 PM, Nokan Emiro wrote: > > Hi, > > I use this in Markaby to generate an html tag, but I need to add lang="lc" > and > xml:lang="lc" (lc != :en). However xhtml_strict does not accept > arguments. :-/ > Why not? And then how should I generate XHTML1.0 Strict docs in other > languages? (I always feel foolish when face with such trivial problems...) > > u. > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Mon Apr 16 15:50:04 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Mon, 16 Apr 2012 17:50:04 +0200 Subject: framework size, forking etc. In-Reply-To: <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> Message-ID: <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Like I've kind of said. I don't want the history of camping to disappear. But I do want to move forward. I'd say create a "classic" branch and put it in a "camping-classic" gem. And then move on with New extra bossy beef Camping for real enterprise jungle guns! (?) Cheers! Isak Andersson Jenna Fox skrev: So the 3kb thing is pretty important to you? Anyone else feel the same way? :) ? Jenna On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: Hi, As a simple user of Camping I would prefer to have a classic and a "modern" one. in one gem or in separate ones, that's not an issue. I would like to use the old one without modifications in my apps, and if I need extra features, I can uncomment/inser a line like this: require 'camping' require 'camping/session' # require 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' Camping.goes :MyApp module MyApp ... But it's just a feature request... u. 2012/4/15 Isak Andersson Ah, no I didn't mean maintaining two versions. Just making sure that everything in current Camping works as it should (not sure it does, my migrations aren't happening) and then freeze it. Call it Camping classic and then re-write it to be well designed for extensibility. With readable code and all. The names for things in our methods should be more then one character l?ng when we aren't worrying about size anymore. Cheers! Isak Andersson david costa skrev: Hi all :) I have been playing with Sinatra a lot lately and perhaps *some* things are done easily there (URL mapping, static files) but being a DSL and not a framework it is a bit different. For many things camping does the job very well and overall I find it a more comprehensive solution than Sinatra. For the classic/new versions I think the issue would be if the main code maintainer (Magnus) should decide if he is willing to do that. Of course other people could do that too but it would still be two versions to maintain or, if you are freezing camping-classic as it is it should at least have a light maintenance that ensures that it would still works fine. Everyone can fork (e.g. camping-couch is a gem with couch db and no active record) the only issue is maintenance and build momentum about it ! Regards David On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: Right. We could just have a branch called "classic" on github. Leaving everything untouched. And then change the gem name to camping-classic or something. Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. Cheers! Isak Andersson Philippe Monnet skrev: On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to "go crazy" and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the "classic" (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the "classic" version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. "... free free set them free ..." On 4/13/2012 9:55 AM, Isak Andersson wrote: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Play Your Favorite Free Games Right On Your Browser - 100% Free! http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of cell phone sites here. Click Here to check them out! http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of math sites here. Click Here to check them out! http://click.lavabit.com/qsuiwstet8g8z7t9968n5rcdn8sa77m5tq4cjmkw3e4ps54wqm3b/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 16:01:39 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 18:01:39 +0200 Subject: framework size, forking etc. In-Reply-To: <0C25A53C-35FC-40C0-8A3A-DE45BAEE3511@innotts.co.uk> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <0C25A53C-35FC-40C0-8A3A-DE45BAEE3511@innotts.co.uk> Message-ID: On Mon, Apr 16, 2012 at 5:40 PM, Dave Everitt wrote: > I'm not too bothered about 3k. But I think what Nokan's saying is that > he'd like Camping to remain functioning as it is so he can continue to run > his apps as they're set up now, but that extra features could be added with > an optional `require 'camping/new_extra_stuff`... - Nokan, is this correct? > Although I've no practical idea about how this might best be achieved - > DaveE > Exactly. That's what I wanted to say. I don't really care about the 3k, however it is charming for me. What I like in Camping is the simplicity. I don't need to be up-to-date in new inventions like in Rails. What I've learnt about Camping N years ago that's still true and works. It's enough if I have a massive Ruby knowledge and I'll be able to solve anything that comes up. Sometimes it is a bit too simple, sometimes it's not logical, and I can understand that people want it to be more supportive while working with it. If you could somehow make the shiny new version an extension of the existing one, then you could keep the 3k (or 4k) limit, and serve the needs of the extra features at the same time. Of course I don't know how to do it, or if it is possible at all. The source of Camping is something that I don't want to see again. :) u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Apr 16 16:18:36 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 16 Apr 2012 17:18:36 +0100 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <0C25A53C-35FC-40C0-8A3A-DE45BAEE3511@innotts.co.uk> Message-ID: <427562A3-9F57-4B3A-8B77-1D328A74B2F4@innotts.co.uk> Awww - the commented version is well worth reading through: https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb DaveE > The source of Camping is something that I don't want to see again. :) From judofyr at gmail.com Mon Apr 16 18:18:14 2012 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 16 Apr 2012 20:18:14 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: On Mon, Apr 16, 2012 at 13:45, Nokan Emiro wrote: > Actually env[] works with mongrel also, not just fcgi or passenger. > (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) Yes, env inside Camping is the same @env (it's just an attr_accessor). Same for @body, @request, @method, @status etc: https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb#L257 From uzleepito at gmail.com Mon Apr 16 18:41:17 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 20:41:17 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: > > > Actually env[] works with mongrel also, not just fcgi or passenger. > > (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) > > Yes, env inside Camping is the same @env (it's just an attr_accessor). > Same for @body, @request, @method, @status etc: > > https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb#L257 Hmmm, maybe I should read through this commented version of source code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 18:50:49 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 20:50:49 +0200 Subject: framework size, forking etc. In-Reply-To: <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: I would leave the name "camping" for the original gem, and would choose another one for the fork. But exactly what are those features that you (all) would like to add to camping? - before/after methods of controllers, - something around serving static files and R(), - ??? Actually I think it's not logical that you can build HTML by default using Markaby, but you can't build CSS in the same way. And I hate the trick with __END__ and appended CSS code. It's not good if you "require" your app into a production environment, for example. u. 2012/4/16 Isak Andersson > ** Like I've kind of said. I don't want the history of camping to > disappear. But I do want to move forward. I'd say create a "classic" branch > and put it in a "camping-classic" gem. And then move on with New extra > bossy beef Camping for real enterprise jungle guns! (?) > > Cheers! > > Isak Andersson > > Jenna Fox skrev: >> >> So the 3kb thing is pretty important to you? Anyone else feel the same >> way? :) >> >> ? >> Jenna >> >> On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: >> >> Hi, >> >> As a simple user of Camping I would prefer to have a classic and >> a "modern" one. in one gem or in separate ones, that's not an issue. >> I would like to use the old one without modifications in my apps, and >> if I need extra features, I can uncomment/inser a line like this: >> >> require 'camping' >> require 'camping/session' >> # require >> 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' >> Camping.goes :MyApp >> module MyApp >> ... >> >> But it's just a feature request... >> >> u. >> >> >> 2012/4/15 Isak Andersson >> >> ** Ah, no I didn't mean maintaining two versions. Just making sure that >> everything in current Camping works as it should (not sure it does, my >> migrations aren't happening) and then freeze it. Call it Camping classic >> and then re-write it to be well designed for extensibility. With readable >> code and all. The names for things in our methods should be more then one >> character l?ng when we aren't worrying about size anymore. >> >> Cheers! >> >> Isak Andersson >> >> david costa skrev: >> >> Hi all :) >> I have been playing with Sinatra a lot lately and perhaps *some* things >> are done easily there (URL mapping, static files) but being a DSL and not a >> framework it is a bit different. For many things camping does the job very >> well and overall I find it a more comprehensive solution than Sinatra. >> >> For the classic/new versions I think the issue would be if the main code >> maintainer (Magnus) should decide if he is willing to do that. Of course >> other people could do that too but it would still be two versions to >> maintain or, if you are freezing camping-classic as it is it should at >> least have a light maintenance that ensures that it would still works fine. >> >> Everyone can fork (e.g. camping-couch is a gem with couch db and no >> active record) the only issue is maintenance and build momentum about it ! >> Regards >> David >> >> >> >> On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson wrote: >> >> Right. We could just have a branch called "classic" on github. Leaving >> everything untouched. >> >> And then change the gem name to camping-classic or something. >> >> Maybe we should rewrite it afterwards (kind of). And make it backwards >> compatible with Camping applications. Just make the infrastructure simple >> and minimalistic. And make it easy to extend and configure. I think this >> would be the best thing ever for Camping more or less. >> >> Cheers! >> >> Isak Andersson >> >> Philippe Monnet skrev: >> >> On one hand everyone is free to fork anything to change radical >> direction. This would allow for the size and some design constraints to be >> eliminated. But on the other hand, at this point in time (since we are the >> new community) shouldn't we free ourselves from the original constraints >> and just ignore the size aspect? I personally think so. It does not mean we >> have to "go crazy" and make it large and complicated (like Rails). >> With the source being on Github, we can just designate the current >> version as the "classic" (super micro version) and document very explicitly >> that from now on we will be free of these constraints and explain how >> people can still get the "classic" version. Since the framework has proven >> extremely stable and resilient, this would not prevent any tinkerer who >> needs the classic version to just do so. >> Although it has been fun to reference the size when talking about >> Camping, keeping it reasonably simple and small is good enough for me. >> >> "... free free set them free ..." >> >> On 4/13/2012 9:55 AM, Isak Andersson wrote: >> >> I agree, I'd like to see the way Camping works to grow in to something >> much more usable. Perhaps a fork is a good idea because the legacy would >> remain and all. But then in the fork we could deal with things that might >> be kind of annoying at times. And grow it with a steady pace. >> >> If we'd fork camping I think we should still stay as minimalistic as >> possible. Only adding the best things. And work on making it easy to extend. >> >> Cheers! >> >> Isak Andersson >> >> Dave Everitt skrev: >> >> There's a crucial point here... if 3k (the old 4k) is a 'proof of >> concept' and a great exercise in programming skill, it isn't something that >> most users will really worry about. If the 3k limit has to be broken back >> up to 4 or even 5k to get some added/altered/optional functionality that >> would help usability for the rest of us, it's not an issue for me - DaveE >> >> 3kb is great and all, but it seems kind of dishonest if the framework >> isn't even really usable without a bunch of other gems and files and stuff. >> The conflict between 3/4kb and having robust well designed features often >> seems to haunt this project. Maybe time for a forking? I have next to no >> interest in 3kb as a real feature. >> >> >> Get the best selection of online sites here. Click Here to check them >> out! >> >> http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ >> >> >> _______________________________________________ >> Camping-list mailing listCamping-list at rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list >> >> >> Play Your Favorite Free Games Right On Your Browser - 100% Free! >> >> http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Get the best selection of cell phone sites here. Click Here to check >> them out! >> >> http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Get the best selection of math sites here. Click Here to check them out! >> >> http://click.lavabit.com/qsuiwstet8g8z7t9968n5rcdn8sa77m5tq4cjmkw3e4ps54wqm3b/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Mon Apr 16 19:20:18 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Mon, 16 Apr 2012 21:20:18 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro napisa?: > Actually I think it's not logical that you can build HTML by default using > Markaby, but you can't?build CSS in the same way. You never need to insert any variables into your CSS code. (If you do, you're doing it wrong.) -- Matma Rex From judofyr at gmail.com Mon Apr 16 19:47:44 2012 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 16 Apr 2012 21:47:44 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: On Sun, Apr 15, 2012 at 01:59, david costa wrote: > Hi all :) > I have been playing with Sinatra a lot lately and perhaps *some* things are > done easily there (URL mapping, static files) but being a DSL and not a > framework it is a bit different. For many things camping does the job very > well and overall I find it a more comprehensive solution than Sinatra. > > For the classic/new versions I think the issue would be if the main code > maintainer (Magnus) should decide if he is willing to do that. Of course > other people could do that too but it would still be two versions to > maintain or, if you are freezing camping-classic as it is it should at least > have a light maintenance that ensures that it would still works fine. For now I'm feeling like a pretty bad "maintainer". I'm not using Camping enough to see where things need to be fixed, I'm crappy at actually shipping stuff, and I'm not sure if I believe that Camping is a correct starting point for a new framework. From uzleepito at gmail.com Mon Apr 16 20:14:59 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 22:14:59 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: 2012/4/16 Bartosz Dziewo?ski > W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro > napisa?: > > Actually I think it's not logical that you can build HTML by default > using > > Markaby, but you can't build CSS in the same way. > > You never need to insert any variables into your CSS code. (If you do, > you're doing it wrong.) > I was not talking about variables. (BTW, lesscss.org is imho great, and the basic concept is to use variables and substitutions instead of the old inheriting way.) But what I was talking about is that Camping is great, because you can create a web application in one single file. However, a web application consist of at least two parts, html and css, and it's some kind of asymmetry that you can only write html in Camping, and you need silly (and sometimes not properly working) tricks to include the css part. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at luon.net Mon Apr 16 20:14:57 2012 From: paul at luon.net (Paul van Tilburg) Date: Mon, 16 Apr 2012 22:14:57 +0200 Subject: framework size, forking etc. In-Reply-To: References: <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: <20120416201455.GB9751@luon.net> On Mon, Apr 16, 2012 at 09:20:18PM +0200, Bartosz Dziewo?ski wrote: > W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro > napisa?: > > Actually I think it's not logical that you can build HTML by default using > > Markaby, but you can't?build CSS in the same way. > > You never need to insert any variables into your CSS code. (If you do, > you're doing it wrong.) I disagree, and you can, use Sass. It works with Rack and thus Camping. http://sass-lang.com/ Paul -- Web: http://paul.luon.net/home/ | E-mail: paul at luon.net Jabber/GTalk: paul at luon.net | GnuPG key ID: 0x50064181 From judofyr at gmail.com Mon Apr 16 20:17:59 2012 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 16 Apr 2012 22:17:59 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: On Mon, Apr 16, 2012 at 22:14, Nokan Emiro wrote: > 2012/4/16 Bartosz Dziewo?ski >> >> W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro >> napisa?: >> > Actually I think it's not logical that you can build HTML by default >> > using >> > Markaby, but you can't?build CSS in the same way. >> >> You never need to insert any variables into your CSS code. (If you do, >> you're doing it wrong.) > > > I was not talking about variables. ?(BTW, lesscss.org is imho great, and > the?basic concept is to use variables and substitutions instead of the old > inheriting way.) ?But what I was talking about is that Camping is great, > because?you can create a web application in one single file. ?However, > a?web application consist of at least two parts, html and css, and it's > some kind of asymmetry that you can only write html in Camping, and > you need silly (and sometimes not properly working) tricks to include the > css part. In the latest Camping from GitHub you can write this: Camping.goes :App __END__ @@ /style.css * { margin: 0; padding: 0 } And Camping will serve it for you. See also: https://github.com/camping/camping/blob/master/test/app_file.rb From ruby at monnet-usa.com Mon Apr 16 20:23:47 2012 From: ruby at monnet-usa.com (Philippe Monnet) Date: Mon, 16 Apr 2012 14:23:47 -0600 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: <4F8C7FD3.306@monnet-usa.com> Everything I actually learned about Camping was by reading the source code as it is quite a feat of engineering. And I learned a ton about metaprogramming too. So it can be quite interesting. :-) On 4/16/2012 12:41 PM, Nokan Emiro wrote: > > > Actually env[] works with mongrel also, not just fcgi or passenger. > > (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) > > Yes, env inside Camping is the same @env (it's just an attr_accessor). > Same for @body, @request, @method, @status etc: > https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb#L257 > > > Hmmm, maybe I should read through this commented version of source code. > > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 20:27:13 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 22:27:13 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: > > > For now I'm feeling like a pretty bad "maintainer". I'm not using > Camping enough to see where things need to be fixed, I'm crappy at > actually shipping stuff, and I'm not sure if I believe that Camping is > a correct starting point for a new framework. > > Like so many times before, I have a few silly questions again: - Why do you think so that Camping isn't a good starting point? - What is the problem with Camping in your opinion? - What does a good framework provide for you? ...and the most stupid one: - Why are you talking about a "new framework"? Why don't we rewrite Sinatra, Ramaze or whatever over Camping? They have an interface that's used by others... u. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at luon.net Mon Apr 16 20:29:03 2012 From: paul at luon.net (Paul van Tilburg) Date: Mon, 16 Apr 2012 22:29:03 +0200 Subject: framework size, forking etc. In-Reply-To: <20120416201455.GB9751@luon.net> References: <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> <20120416201455.GB9751@luon.net> Message-ID: <20120416202903.GC9751@luon.net> On Mon, Apr 16, 2012 at 10:14:57PM +0200, Paul van Tilburg wrote: > On Mon, Apr 16, 2012 at 09:20:18PM +0200, Bartosz Dziewo?ski wrote: > > W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro > > napisa?: > > > Actually I think it's not logical that you can build HTML by default using > > > Markaby, but you can't?build CSS in the same way. > > > > You never need to insert any variables into your CSS code. (If you do, > > you're doing it wrong.) > > I disagree, and you can, use Sass. It works with Rack and thus Camping. > > http://sass-lang.com/ I have to add that that works differently because you don't use it like a DSL in Camping like Markaby. Then again, Markaby can be replaced via Tilt by anything and that can make it more symmetric. Paul -- Web: http://paul.luon.net/home/ | E-mail: paul at luon.net Jabber/GTalk: paul at luon.net | GnuPG key ID: 0x50064181 From uzleepito at gmail.com Mon Apr 16 20:45:13 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 22:45:13 +0200 Subject: http_referrer In-Reply-To: <4F8C7FD3.306@monnet-usa.com> References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <4F8C7FD3.306@monnet-usa.com> Message-ID: I'm totally convinced... so I'm going to download the whole source before the guys start to rewrite it as a "modern framework"... :) But to be frank, this, for instance, is not so great to read: https://github.com/camping/camping/blob/master/lib/camping.rb I mean I'm big http://catseye.tc/ fan, but when I'm working on a site, it's not a big flash to try to find out something from that ~ camping.min.rb u. On Mon, Apr 16, 2012 at 10:23 PM, Philippe Monnet wrote: > Everything I actually learned about Camping was by reading the source > code as it is quite a feat of engineering. > And I learned a ton about metaprogramming too. So it can be quite > interesting. :-) > > > On 4/16/2012 12:41 PM, Nokan Emiro wrote: > > > Actually env[] works with mongrel also, not just fcgi or passenger. >> > (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) >> >> Yes, env inside Camping is the same @env (it's just an attr_accessor). >> Same for @body, @request, @method, @status etc: >> >> https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb#L257 > > > Hmmm, maybe I should read through this commented version of source code. > > > > > _______________________________________________ > Camping-list mailing listCamping-list at rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 20:55:15 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 22:55:15 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: Shit! If you told me about it a few hours ago, I wouldn't bother myself writing a RobotsTxt Controller... __END__ > @@ /style.css > * { margin: 0; padding: 0 } > > And Camping will serve it for you. See also: > https://github.com/camping/camping/blob/master/test/app_file.rb > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Mon Apr 16 20:59:18 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Mon, 16 Apr 2012 22:59:18 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <4F8C7FD3.306@monnet-usa.com> Message-ID: W dniu 16 kwietnia 2012 22:45 u?ytkownik Nokan Emiro napisa?: > I'm totally convinced... ?so I'm going to download the whole source > before the?guys start to rewrite it as a "modern framework"... :) > > But to be frank, this, for instance, is not so great to read: > https://github.com/camping/camping/blob/master/lib/camping.rb > > I mean I'm big?http://catseye.tc/?fan, but when I'm working on a site, > it's?not a big flash to try to find out something from that ~ camping.min.rb You do realize that there exists an annotated version of source, with comments, proper indentation and (whoa!) some whitespace? https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb -- Matma Rex From gurugeekphp at gmail.com Mon Apr 16 21:09:11 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 16 Apr 2012 23:09:11 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: > > > For now I'm feeling like a pretty bad "maintainer". I'm not using > Camping enough to see where things need to be fixed, I'm crappy at > actually shipping stuff, and I'm not sure if I believe that Camping is > a correct starting point for a new framework Hey Magnus! I think that you are a great maintainer as you kept Camping in good standing and bug free. That is more than enough :) I would agree the camping as a starting base for a new framework might not be ideal. As far as I know Camping was not intended to compete with rails (or anything else) but was more of a small, learning framework and given that _why did so many projects for beginners and education purposes this would fit in this category I think. It doesn't mean that camping is not cool or not as good as other frameworks bur, for what I can see, the initial idea was to have something simple and quick. There are so many frameworks e.g. even the core of Ramaze ( https://github.com/Ramaze/innate) available to build other frameworks. But does the world really need a new framework ? :) In honesty I think that if someone wants to do that it should either provide the coding power or be sure that Magnus buys into the idea and is willing to code that as per your idea. For me the current camping is sufficiently good in *most* cases but of course not all...no framework really is and there is no silver bullet. I don't think it would be something bad if anyone would say "hey for this project I prefer Sinatra as it does the job in a different/more elegant way than camping". What I think camping misses is more marking/visibility to attract more users and volunteers. Or what do you think ? Is camping at the moment complete as it is and the future code side would mostly be focused on bug cleaning/maintenance ? Best Regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruby at monnet-usa.com Mon Apr 16 21:11:06 2012 From: ruby at monnet-usa.com (Philippe Monnet) Date: Mon, 16 Apr 2012 15:11:06 -0600 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <4F8C7FD3.306@monnet-usa.com> Message-ID: <4F8C8AEA.9050005@monnet-usa.com> I think Nokan has a good point there: it is not easy for people new to Camping to know about the trick to compile/process/compact the source code. So an idea for the "new" version could be to leave the source as is (unabridged). Plus this makes debugging easier. :-) On 4/16/2012 2:59 PM, Bartosz Dziewo?ski wrote: > W dniu 16 kwietnia 2012 22:45 u?ytkownik Nokan Emiro > napisa?: >> I'm totally convinced... so I'm going to download the whole source >> before the guys start to rewrite it as a "modern framework"... :) >> >> But to be frank, this, for instance, is not so great to read: >> https://github.com/camping/camping/blob/master/lib/camping.rb >> >> I mean I'm big http://catseye.tc/ fan, but when I'm working on a site, >> it's not a big flash to try to find out something from that ~ camping.min.rb > You do realize that there exists an annotated version of source, with > comments, proper indentation and (whoa!) some whitespace? > https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Mon Apr 16 21:13:46 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Mon, 16 Apr 2012 23:13:46 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <4F8C7FD3.306@monnet-usa.com> Message-ID: 2012/4/16 Bartosz Dziewo?ski > You do realize that there exists an annotated version of source, with > comments, proper indentation and (whoa!) some whitespace? > https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb > > No, actually I did know that there's an indented version, but the nice comments are new to me. It's a whole book! ...but it isn't <= 4k... ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Mon Apr 16 21:13:49 2012 From: gurugeekphp at gmail.com (david costa) Date: Mon, 16 Apr 2012 23:13:49 +0200 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> <4F8C7FD3.306@monnet-usa.com> Message-ID: Well the point of the original camping was *not* to be easy to read nor to have camping used in the next big commercial project. The annotated version gives you pretty much all you want if you want to read it :) On Mon, Apr 16, 2012 at 10:59 PM, Bartosz Dziewo?ski wrote: > W dniu 16 kwietnia 2012 22:45 u?ytkownik Nokan Emiro > napisa?: > > I'm totally convinced... so I'm going to download the whole source > > before the guys start to rewrite it as a "modern framework"... :) > > > > But to be frank, this, for instance, is not so great to read: > > https://github.com/camping/camping/blob/master/lib/camping.rb > > > > I mean I'm big http://catseye.tc/ fan, but when I'm working on a site, > > it's not a big flash to try to find out something from that ~ > camping.min.rb > > You do realize that there exists an annotated version of source, with > comments, proper indentation and (whoa!) some whitespace? > https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Apr 17 10:23:51 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 17 Apr 2012 12:23:51 +0200 Subject: framework size, forking etc. In-Reply-To: References: <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> To be honest I don't care if we leave the 4k stuff behind or not. I just want Camping to be easy to extend and customize. Don't get me wrong, Camping is crazy customizable. The fact that you can set it up to be a huuuuuge application with the rackup file in an extremely cool way is definitely something special. Ps. Now that we mentioned bugs. I'm not sure that Camping is calling App.create anymore in the latest version from gems.judofyr.net. I did open an issue from it on github. I don't get any database tables. And I'm sort of stuck with the f?rst screencast because of it :( Cheers! Isak Andersson -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Tue Apr 17 11:25:07 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Tue, 17 Apr 2012 12:25:07 +0100 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <9069c85d-afe3-4463-bf5b-50b2a4bdcd8a@email.android.com> <56B00FA1E7C4424E8D43CCF10F936CB2@creativepony.com> <85e764bb-e70a-4d6e-a1ac-0b772a71045e@email.android.com> Message-ID: If you want to use something like SASS for CSS, there are gems for that (or use LESS), but I'd never expect such functionality to be built into in Camping - that's one of the things I *like* about it: a small functional default set that works, with options for other ways left to me. BTW the only CSS variables I ever wanted (or used with various methods) are for colours, and you can even do that with SSI. Also, __END__ isn't solely a Camping thing, it's an option with any Ruby script (as it is with Perl), so no need to use it if you don't want to. - DaveE >> Actually I think it's not logical that you can build HTML by >> default using Markaby, but you can't build CSS in the same way. >> And I hate the trick with __END__ and appended CSS code. > > You never need to insert any variables into your CSS code. (If you > do, you're doing it wrong.) > > -- Matma Rex From deveritt at innotts.co.uk Tue Apr 17 12:23:46 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Tue, 17 Apr 2012 13:23:46 +0100 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: +1 to all that David Costa wrote in response. Magnus *has and does* kept things solid and on track in a way that suits Camping. We're never going to go head-to-head in the framework competition stakes (bit late for that anyway, with frameworks swerving all over client- side dev). As for encouraging new users - not actively trying to pull them in (madness :-) - providing a Camping-specific deployment platform as a visible part of the public face of Camping is a MASSIVE positive (thanks David: I've been merrily using it after losing too many days hacking my live servers). A simple deployment guide for the various common scenarios (shared hosting, cloud, VPS) as part of the book would round off the experience - I'd be more than happy to edit and collate that. The 'small is beautiful' and refreshingly globally diverse Camping community works for me, and I wouldn't want much more mail from the list than I get now :-) although it's a great evolutionary drive whenever there's an activity spike and things get aired in public... Magnus does a good job (look at the GitHub commits), Jenna took on the challenge of a new website, and others can support and add to those very concrete contributions (as Sean did recently with the book), but I'd never want anyone to feel obliged or get too concerned about promotion - that's just not relaxed enough for Camping (it's the little wheels, remember :-) Any framework is going to have limitations, the question is: are these becoming a *real* problem (if so, which one is the #1 candidate for change), or are they to be accepted as part of the character of the framework? DaveE > For now I'm feeling like a pretty bad "maintainer". I'm not using > Camping enough to see where things need to be fixed, I'm crappy at > actually shipping stuff, and I'm not sure if I believe that Camping is > a correct starting point for a new framework > > Hey Magnus! I think that you are a great maintainer as you kept > Camping in good standing and bug free. That is more than enough :) > I would agree the camping as a starting base for a new framework > might not be ideal. As far as I know Camping was not intended to > compete with rails (or anything else) > but was more of a small, learning framework and given that _why did > so many projects for beginners and education purposes this would fit > in this category I think. > > It doesn't mean that camping is not cool or not as good as other > frameworks bur, for what I can see, the initial idea was to have > something simple and quick. > > There are so many frameworks e.g. even the core of Ramaze (https://github.com/Ramaze/innate > ) available to build other frameworks. But does the world really > need a new framework ? :) > In honesty I think that if someone wants to do that it should either > provide the coding power or be sure that Magnus buys into the idea > and is willing to code that as per your idea. > > For me the current camping is sufficiently good in *most* cases but > of course not all...no framework really is and there is no silver > bullet. I don't think it would be something bad if anyone would say > "hey for this project I prefer Sinatra as it does the job in a > different/more elegant way than camping". > > What I think camping misses is more marking/visibility to attract > more users and volunteers. Or what do you think ? Is camping at the > moment complete as it is and the future code side would mostly be > focused on bug cleaning/maintenance ? > Best Regards > David > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Tue Apr 17 14:37:58 2012 From: gurugeekphp at gmail.com (david costa) Date: Tue, 17 Apr 2012 16:37:58 +0200 Subject: framework size, forking etc. In-Reply-To: <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> References: <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> Message-ID: Isak, may be you should use the official release for the screencast no ? If is a screencast about something not yet released what is the use of it... On Tue, Apr 17, 2012 at 12:23 PM, Isak Andersson wrote: > To be honest I don't care if we leave the 4k stuff behind or not. I just > want Camping to be easy to extend and customize. Don't get me wrong, > Camping is crazy customizable. The fact that you can set it up to be a > huuuuuge application with the rackup file in an extremely cool way is > definitely something special. > > Ps. > > Now that we mentioned bugs. I'm not sure that Camping is calling > App.create anymore in the latest version from gems.judofyr.net. I did > open an issue from it on github. I don't get any database tables. And I'm > sort of stuck with the f?rst screencast because of it :( > > Cheers! > > Isak Andersson > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Apr 17 16:17:42 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 17 Apr 2012 18:17:42 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> Message-ID: I thought about that, but I want to stay up to date with things like Mab and all that. There are small differences. But I guess I could omit the use of anything that differs. But still, we want the information to be fresh, no? Cheers! Isak Andersson david costa skrev: Isak, may be you should use the official release for the screencast no ? If is a screencast about something not yet released what is the use of it... On Tue, Apr 17, 2012 at 12:23 PM, Isak Andersson wrote: To be honest I don't care if we leave the 4k stuff behind or not. I just want Camping to be easy to extend and customize. Don't get me wrong, Camping is crazy customizable. The fact that you can set it up to be a huuuuuge application with the rackup file in an extremely cool way is definitely something special. Ps. Now that we mentioned bugs. I'm not sure that Camping is calling App.create anymore in the latest version from gems.judofyr.net. I did open an issue from it on github. I don't get any database tables. And I'm sort of stuck with the f?rst screencast because of it :( Cheers! Isak Andersson _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Ein groartiges Angebot jeden Tag. Erlebe Deine Stadt zum besten Preis http://click.lavabit.com/yw43wb87merdsyqa1obkgr1b5s77kkig8yyupurhynbx5gsjpmab/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Apr 17 16:19:50 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 17 Apr 2012 18:19:50 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: <837c7e1e-f393-4e53-a746-721eaad05d3a@email.android.com> Agreed, Magnus does an amazing job with Camping! More than anyone else has done anyway. Cheers! Isak Andersson Dave Everitt skrev: +1 to all that David Costa wrote in response. Magnus *has and does* kept things solid and on track in a way that suits Camping. We're never going to go head-to-head in the framework competition stakes (bit late for that anyway, with frameworks swerving all over client-side dev). As for encouraging new users - not actively trying to pull them in (madness :-) - providing a Camping-specific deployment platform as a visible part of the public face of Camping is a MASSIVE positive (thanks David: I've been merrily using it after losing too many days hacking my live servers). A simple deployment guide for the various common scenarios (shared hosting, cloud, VPS) as part of the book would round off the experience - I'd be more than happy to edit and collate that. The 'small is beautiful' and refreshingly globally diverse Camping community works for me, and I wouldn't want much more mail from the list than I get now :-) although it's a great evolutionary drive whenever there's an activity spike and things get aired in public... Magnus does a good job (look at the GitHub commits), Jenna took on the challenge of a new website, and others can support and add to those very concrete contributions (as Sean did recently with the book), but I'd never want anyone to feel obliged or get too concerned about promotion - that's just not relaxed enough for Camping (it's the little wheels, remember :-) Any framework is going to have limitations, the question is: are these becoming a *real* problem (if so, which one is the #1 candidate for change), or are they to be accepted as part of the character of the framework? DaveE For now I'm feeling like a pretty bad "maintainer". I'm not using Camping enough to see where things need to be fixed, I'm crappy at actually shipping stuff, and I'm not sure if I believe that Camping is a correct starting point for a new framework Hey Magnus! I think that you are a great maintainer as you kept Camping in good standing and bug free. That is more than enough :) I would agree the camping as a starting base for a new framework might not be ideal. As far as I know Camping was not intended to compete with rails (or anything else) but was more of a small, learning framework and given that _why did so many projects for beginners and education purposes this would fit in this category I think. It doesn't mean that camping is not cool or not as good as other frameworks bur, for what I can see, the initial idea was to have something simple and quick. There are so many frameworks e.g. even the core of Ramaze (https://github.com/Ramaze/innate) available to build other frameworks. But does the world really need a new framework ? :) In honesty I think that if someone wants to do that it should either provide the coding power or be sure that Magnus buys into the idea and is willing to code that as per your idea. For me the current camping is sufficiently good in *most* cases but of course not all...no framework really is and there is no silver bullet. I don't think it would be something bad if anyone would say "hey for this project I prefer Sinatra as it does the job in a different/more elegant way than camping". What I think camping misses is more marking/visibility to attract more users and volunteers. Or what do you think ? Is camping at the moment complete as it is and the future code side would mostly be focused on bug cleaning/maintenance ? Best Regards David _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get The Best Grades With the Least Amount of Time &Effort ! http://click.lavabit.com/4y9ywgcjjpcupwjmu88dbj7fqhkuwrgiab3x6bdnpbn6fwz7am8y/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Tue Apr 17 16:44:49 2012 From: gurugeekphp at gmail.com (david costa) Date: Tue, 17 Apr 2012 18:44:49 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> Message-ID: Well Sqlite works fine with the current camping so I don't see any reason to use something not yet released for the screencasts. so in short use the official camping-omnibus for the screencasts. I checked your issue on github but I don't think is the fault of the new version but that's not the point really :) I just feel for Magnus that has to debug all our code... If we manage to get some good screencasts adding a new one when the new version will be out will be very easy so.. On Tue, Apr 17, 2012 at 6:17 PM, Isak Andersson wrote: > ** I thought about that, but I want to stay up to date with things like > Mab and all that. There are small differences. But I guess I could omit the > use of anything that differs. But still, we want the information to be > fresh, no? > > Cheers! > > Isak Andersson > > david costa skrev: >> >> Isak, >> may be you should use the official release for the screencast no ? If is >> a screencast about something not yet released what is the use of it... >> >> On Tue, Apr 17, 2012 at 12:23 PM, Isak Andersson wrote: >> >>> To be honest I don't care if we leave the 4k stuff behind or not. I just >>> want Camping to be easy to extend and customize. Don't get me wrong, >>> Camping is crazy customizable. The fact that you can set it up to be a >>> huuuuuge application with the rackup file in an extremely cool way is >>> definitely something special. >>> >>> Ps. >>> >>> Now that we mentioned bugs. I'm not sure that Camping is calling >>> App.create anymore in the latest version from gems.judofyr.net. I did >>> open an issue from it on github. I don't get any database tables. And I'm >>> sort of stuck with the f?rst screencast because of it :( >>> >>> Cheers! >>> >>> Isak Andersson >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> Ein groartiges Angebot jeden Tag. Erlebe Deine Stadt zum besten Preis >> >> http://click.lavabit.com/yw43wb87merdsyqa1obkgr1b5s77kkig8yyupurhynbx5gsjpmab/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Tue Apr 17 20:15:43 2012 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 17 Apr 2012 22:15:43 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: On Mon, Apr 16, 2012 at 22:27, Nokan Emiro wrote: >> >> For now I'm feeling like a pretty bad "maintainer". I'm not using >> Camping enough to see where things need to be fixed, I'm crappy at >> actually shipping stuff, and I'm not sure if I believe that Camping is >> a correct starting point for a new framework. > > Like so many times before, I have a few silly questions again: There's no silly questions; just puzzled people who don't dare to ask :-) > - Why do you think so that Camping isn't a good starting point? I like centralized routing (config/routes.rb vs having routes in the controllers). It's also easier to combine a Sinatra-style-framework with centralized routing: just allow routing to a block, and `get "/" do ? end` is as natural as `routes.get "/", :to => "home#index"`. I prefer Sinatra-style routes over regexps. Camping's module magic is just plain bad style. Inheritance is easier to work with. Mapping one URL to one class is a little too verbose for me; I end up with tons of classes and it's hard to see which classes that actually work on the same type of data. For controller classes, Rails-style is more pragmatic. It's just 4k; that's hardly any starting point at all :-) > - What is the problem with Camping in your opinion? There's not a "problem" with Camping. It's an elegant piece of code; it solves HTTP in a surprisingly "correct" way, although it's not always so pragmatic/practical. > - What does a good framework provide for you? > > ...and the most stupid one: > > - Why are you talking about a "new framework"? ?Why don't we > rewrite Sinatra, Ramaze or whatever?over?Camping? ?They have > an interface that's used by others... I just feel like the whole Ruby framework community stagnated a few years after we got Rack. The moment Rack became properly implemented everywhere it lacked any kind of EventStream/WebSocket/long-polling-support. Everything since then has been hacked on top. Rails provides ActiveRecord for database access, but more and more stuff these days are using HTTP. I believe that a true *web* framework should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it (no persistant connection support in stdlib; rather verbose/inconsistent and no cookie-jar). There are other libraries, but these have their own conventions and limitations. From gurugeekphp at gmail.com Tue Apr 17 20:50:58 2012 From: gurugeekphp at gmail.com (david costa) Date: Tue, 17 Apr 2012 22:50:58 +0200 Subject: whitespace rendering Message-ID: Hello ! perhaps this might be a n00b markaby question but...we are finding some issues to display records with a simple space inside a view (both with sqlite, mysql or kirbybase so it is not db related). E.g. to have a formatted (with a simple space between the records so nothing fancy like Stock Name Apple Ticker AAPL number of stocks 10 bought at 580.13$ on 2012-04-17 Total position 5801.3) list I have to do something like this def index kirby = KirbyBase.new stocks_tbl = kirby.get_table(:stocks) results = stocks_tbl.select(:name,:ticker,:tradeprice,:tradedate,:quantity,:totalposition,:recno).sort(+:totalposition) for result in results text 'Stock Name  ' text result.name text ' ' text 'Ticker  ' text result.ticker text ' ' text 'number of stocks' text ' ' text result.quantity text ' ' text 'bought at  ' text result.tradeprice text '$  ' text 'on  ' text result.tradedate text ' ' text 'Total position' text ' ' text result.totalposition br Now I am sure that there is perhaps a better way to do it ? :) Thanks in advance David -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Tue Apr 17 21:11:39 2012 From: gurugeekphp at gmail.com (david costa) Date: Tue, 17 Apr 2012 23:11:39 +0200 Subject: whitespace rendering In-Reply-To: References: Message-ID: oh well I found my own answer this is intentional in maraby so best way to do a table like below - sorry for asking and answering my own question :) table do tr do td 'Stock Name' td 'Ticker' td 'Number of Stocks' td 'Price' td 'Date' td 'Total Position' end for result in results tr do td result.name td result.ticker td result.quantity td result.tradeprice td result.tradedate td result.totalposition end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Apr 17 22:48:12 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Wed, 18 Apr 2012 00:48:12 +0200 Subject: framework size, forking etc. In-Reply-To: References: <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> <3ff52143-7709-41f1-96e0-9e0fec6b3dbf@email.android.com> Message-ID: <5642e482-96d6-4f50-917b-fe30805623d6@email.android.com> Yeah I was going to suggest that we do a screencasts going over New features. Let's go with that instead! Cheers! Isak Andersson david costa skrev: Well Sqlite works fine with the current camping so I don't see any reason to use something not yet released for the screencasts. so in short use the official camping-omnibus for the screencasts. I checked your issue on github but I don't think is the fault of the new version but that's not the point really :) I just feel for Magnus that has to debug all our code... If we manage to get some good screencasts adding a new one when the new version will be out will be very easy so.. On Tue, Apr 17, 2012 at 6:17 PM, Isak Andersson wrote: I thought about that, but I want to stay up to date with things like Mab and all that. There are small differences. But I guess I could omit the use of anything that differs. But still, we want the information to be fresh, no? Cheers! Isak Andersson david costa skrev: Isak, may be you should use the official release for the screencast no ? If is a screencast about something not yet released what is the use of it... On Tue, Apr 17, 2012 at 12:23 PM, Isak Andersson wrote: To be honest I don't care if we leave the 4k stuff behind or not. I just want Camping to be easy to extend and customize. Don't get me wrong, Camping is crazy customizable. The fact that you can set it up to be a huuuuuge application with the rackup file in an extremely cool way is definitely something special. Ps. Now that we mentioned bugs. I'm not sure that Camping is calling App.create anymore in the latest version from gems.judofyr.net. I did open an issue from it on github. I don't get any database tables. And I'm sort of stuck with the f?rst screencast because of it :( Cheers! Isak Andersson _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Ein groartiges Angebot jeden Tag. Erlebe Deine Stadt zum besten Preis http://click.lavabit.com/yw43wb87merdsyqa1obkgr1b5s77kkig8yyupurhynbx5gsjpmab/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Get the best selection of web mail sites here. Click Here to check them out! http://click.lavabit.com/zskuijyi496mffdy7qiz1o45toiyshg1nsczzppt7zzi9tpa9udb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Tue Apr 17 23:13:33 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 18 Apr 2012 00:13:33 +0100 Subject: http_referrer In-Reply-To: References: <3C68E2E6-45BC-43F6-AB36-80D54462945F@innotts.co.uk> Message-ID: Just to be clear (obviously env vars are going to differ according to setup, but): when env is used inside Camping, it's equivalent to @env and get Rack env vars when ENV is used, it will get any other environment variables, not just from Passenger etc. but also any set by the system. With a view to making a little app/snippet to show all available env vars I've been looking at them on David's Camping server (they only appear with the query string at the end of the URL): http://dave.camping.sh/sites?vars But the Rack vars don't seem to format nicely with key value pairs (breaks when I try): env.each_pair do |name,value| so I just made a line for each with env.each do |name| - source here: https://github.com/DaveEveritt/Camping-links/blob/master/www/camplinks.rb DaveE > On Mon, Apr 16, 2012 at 13:45, Nokan Emiro > wrote: >> Actually env[] works with mongrel also, not just fcgi or passenger. >> (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) > > Yes, env inside Camping is the same @env (it's just an attr_accessor). > Same for @body, @request, @method, @status etc: > https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb > #L257 > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From deveritt at innotts.co.uk Tue Apr 17 23:13:39 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 18 Apr 2012 00:13:39 +0100 Subject: http_referrer In-Reply-To: <20120414110829.GA4767@s.clearwire-wmx.net> References: <0E485167-6C64-460A-877B-0817F5CB59B4@innotts.co.uk> <20120414110829.GA4767@s.clearwire-wmx.net> Message-ID: Hi cdr - thanks for this, but I've not been able to do key value on the Rack envs as some seem to have a different format - see the other post I added to this thread - DaveE > how Rack env vars are stored, and how > to get a nice printout? > > i defined #to_html on everything. on Array thats > > map(&:html).join ', ' > > on Hash it prints a , Object is html_escape(to_s) > > > Rack just iterates thru env in an ERB template: > >

Rack ENV

>
> > > > > > > > <% env.sort_by { |k, v| k.to_s }.each { |key, val| %> > > > > > <% } %> > >
VariableValue
<%=h key %>
<%=h val %>
From a at creativepony.com Wed Apr 18 00:35:33 2012 From: a at creativepony.com (Jenna Fox) Date: Wed, 18 Apr 2012 10:35:33 +1000 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: Those are all great points - the eventstream support is a particular sticking point to me. It feels like a standard which aught to be easily implemented - even through rack! but I've yet to see any web frameworks where eventstream doesn't seem like a total hack - except perhaps for Node.JS where the http server class is so low level anything seems equally easy. I'm not yet convinced WebSocket is useful for very much - it's not well supported in http servers and reverse http proxies, and it's full-duplex nature seems unnecessary when ajax is good enough for responding in most situations. On the other hand, websockets doesn't even pretend to be anything like a http request aside from setup negotiation, so there's no implication that a web framework designed for serving pages should really have anything to do with websocket - much of the websocket standards specify outputting strings which look like http, but not really parsing http headers properly or anything. I'd love to see some inventive solutions to long polling and event stream. Rack does seem to be increasingly a source of pain. The guardians of the rack spec haven't done a good job keeping up with new tech. All your other points, I totally agree. Especially regexp routes. I feel like the camping feature for generating routes from controller names is not as good as just having a friendly route language. One thing I never liked about rails was having routes in a separate file somewhere, then just some controllers named whatever files. I wonder if the controller routes couldn't also be the controller's filenames? I guess some operating systems wouldn't much like filenames with forward slashes in them though (windows..) ? Jenna On Wednesday, 18 April 2012 at 6:15 AM, Magnus Holm wrote: > On Mon, Apr 16, 2012 at 22:27, Nokan Emiro wrote: > > > > > > For now I'm feeling like a pretty bad "maintainer". I'm not using > > > Camping enough to see where things need to be fixed, I'm crappy at > > > actually shipping stuff, and I'm not sure if I believe that Camping is > > > a correct starting point for a new framework. > > > > > > > > > Like so many times before, I have a few silly questions again: > > There's no silly questions; just puzzled people who don't dare to ask :-) > > > - Why do you think so that Camping isn't a good starting point? > > I like centralized routing (config/routes.rb vs having routes in the > controllers). It's also easier to combine a Sinatra-style-framework > with centralized routing: just allow routing to a block, and `get "/" > do ? end` is as natural as `routes.get "/", :to => "home#index"`. > > I prefer Sinatra-style routes over regexps. > > Camping's module magic is just plain bad style. Inheritance is easier > to work with. > > Mapping one URL to one class is a little too verbose for me; I end up > with tons of classes and it's hard to see which classes that actually > work on the same type of data. For controller classes, Rails-style is > more pragmatic. > > It's just 4k; that's hardly any starting point at all :-) > > > - What is the problem with Camping in your opinion? > > There's not a "problem" with Camping. It's an elegant piece of code; > it solves HTTP in a surprisingly "correct" way, although it's not > always so pragmatic/practical. > > > - What does a good framework provide for you? > > > > ...and the most stupid one: > > > > - Why are you talking about a "new framework"? Why don't we > > rewrite Sinatra, Ramaze or whatever over Camping? They have > > an interface that's used by others... > > > > > I just feel like the whole Ruby framework community stagnated a few > years after we got Rack. The moment Rack became properly implemented > everywhere it lacked any kind of > EventStream/WebSocket/long-polling-support. Everything since then has > been hacked on top. > > Rails provides ActiveRecord for database access, but more and more > stuff these days are using HTTP. I believe that a true *web* framework > should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it > (no persistant connection support in stdlib; rather > verbose/inconsistent and no cookie-jar). There are other libraries, > but these have their own conventions and limitations. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danbryan at gmail.com Wed Apr 18 13:07:15 2012 From: danbryan at gmail.com (Daniel Bryan) Date: Wed, 18 Apr 2012 23:07:15 +1000 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: Thought I'd weigh in for what it's worth, My naive first impression of Camping basically took no notice of the whole 3/4k thing. I appreciate that it's a cool programming feat, and I love the attitude that lead to it, but at the time my focus was on trying to figure out what all these hidden instance variables you have in a controller are (the documentation was only of sporadic use), thinking I might just dive into the source to check it out, and obviously being confronted by the fact that even the unabridged code is far from readable (as it wasn't intended to be). I discovered Camping when I was very new to Ruby, and relatively new to programming in general. Everyone here obviously knows the strengths and reputation of Ruby - and projects like Camping - as a learning language. I've mostly moved onto working in Python, but I think there's a strong chance that my understanding of the architecture of web applications, and HTTP, and my motivation to understand web development at several different layers, would have been different if Camping didn't imply a certain kind of thinking that coloured my behaviour. So why not build on this? There's all sorts of amazing projects all over the web at the moment for making programming accessible to people who are very young, or who have literacy that's poorer than most programmers, or who live in the third world, or who just come from subcultures / cliques where usually you wouldn't do this kind of thing. That's cool, but as soon as these people learn some stuff they want to *do something*, and they want to do it either with mobile or the web. They google around and they find out about, like, what? Rails? Django? What a way to turn people off. One of the reasons I floundered with Camping after a while is that it was really hard to figure out where to, you know, put a lot of my code. Helpers? I guess. This is a pretty typical problem in web frameworks, obviously - where do you put domain-specific logic? Where do you store all your application logic? How lightweight should your controllers be? Do you want fat models? I think ActiveRecord is the elephant in the room here - very quickly I ended up using models in my apps that were just representations of the filesystem, or of some other API, or of documents in CouchDB, or whatever. That was cool, and Camping made that relatively easy, but the fact is I'm not an API designer. I'm not a library writer. Any ad-hoc decision I make about how I might model my data, as an amateurish programmer, is going to be disastrous, but ActiveRecord just couldn't do what I wanted to do without more work than it was worth. So maybe if there was some kind of Camping fork, or a new Camping-inspired framework, or whatever, it could try to encapsulate not just this solid core focused on using class methods as HTTP verbs, but also some kind of pattern. What's the next thing someone needs to know after they're good with Camping? How to write their library code. How to manage the dependencies (ugh). How to deploy it (it took me *forever* to even figure out that I needed something called a 'rackup' file - I eventually found a Heroku guide for Camping, and even then I couldn't get it to work until I stole some code from some project of Magnus' or Jenna's). I'm being incoherent, but in general I think my attraction as a novice to Camping was for it clarity - not even necessarily its simplicity. Why not bring that clarity to the rest of the web development process that surrounds it? People keep talking about Sinatra. Personally - as a completely subjective, essentially arbitrary position - I don't like Sinatra. Whatever you think of it, I think it's possible to point out that we don't need to just look inside the Ruby environment. Why not look at other places where interesting things are happening? Node's "Express" framework, for instance, bears a lot of similarity to Sinatra and Camping; the "Connect" middleware framework that it uses is similar to Rack in many ways. The difference is that their community actually brags about it, and makes a point of how much easier your life could be if you use it for lots of stuff. It looks like there was similar excitement about Rack back in the day, but it doesn't come across that way so much. Maybe just because of the shadow of Rails hanging over everything. Sorry for ranting a little - I keep reading this thread on the way to work and wanting to comment but not having time. In summary - I'm greatful for what Camping provided me as a learning environment, but I think it could go a lot further in supporting the growth of developers who used it, and helping them to do stuff 'correctly' outside of their controllers. It's obvious that sockets and so on excite a lot of young programmers - especially as so many of them have JavaScript as their first language now, but I can't imagine how you'd support something like that properly in something like Camping without building it on top of an event-driven framework. On Wed, Apr 18, 2012 at 10:35 AM, Jenna Fox wrote: > Those are all great points - the eventstream support is a particular > sticking point to me. It feels like a standard which aught to be easily > implemented - even through rack! but I've yet to see any web frameworks > where eventstream doesn't seem like a total hack - except perhaps for > Node.JS where the http server class is so low level anything seems equally > easy. I'm not yet convinced WebSocket is useful for very much - it's not > well supported in http servers and reverse http proxies, and it's > full-duplex nature seems unnecessary when ajax is good enough for > responding in most situations. On the other hand, websockets doesn't even > pretend to be anything like a http request aside from setup negotiation, so > there's no implication that a web framework designed for serving pages > should really have anything to do with websocket - much of the websocket > standards specify outputting strings which look like http, but not really > parsing http headers properly or anything. > > I'd love to see some inventive solutions to long polling and event stream. > Rack does seem to be increasingly a source of pain. The guardians of the > rack spec haven't done a good job keeping up with new tech. > > All your other points, I totally agree. Especially regexp routes. I feel > like the camping feature for generating routes from controller names is not > as good as just having a friendly route language. > > One thing I never liked about rails was having routes in a separate file > somewhere, then just some controllers named whatever files. I wonder if the > controller routes couldn't also be the controller's filenames? I guess some > operating systems wouldn't much like filenames with forward slashes in them > though (windows..) > > ? > Jenna > > On Wednesday, 18 April 2012 at 6:15 AM, Magnus Holm wrote: > > On Mon, Apr 16, 2012 at 22:27, Nokan Emiro wrote: > > > For now I'm feeling like a pretty bad "maintainer". I'm not using > Camping enough to see where things need to be fixed, I'm crappy at > actually shipping stuff, and I'm not sure if I believe that Camping is > a correct starting point for a new framework. > > > Like so many times before, I have a few silly questions again: > > > There's no silly questions; just puzzled people who don't dare to ask :-) > > - Why do you think so that Camping isn't a good starting point? > > > I like centralized routing (config/routes.rb vs having routes in the > controllers). It's also easier to combine a Sinatra-style-framework > with centralized routing: just allow routing to a block, and `get "/" > do ? end` is as natural as `routes.get "/", :to => "home#index"`. > > I prefer Sinatra-style routes over regexps. > > Camping's module magic is just plain bad style. Inheritance is easier > to work with. > > Mapping one URL to one class is a little too verbose for me; I end up > with tons of classes and it's hard to see which classes that actually > work on the same type of data. For controller classes, Rails-style is > more pragmatic. > > It's just 4k; that's hardly any starting point at all :-) > > - What is the problem with Camping in your opinion? > > > There's not a "problem" with Camping. It's an elegant piece of code; > it solves HTTP in a surprisingly "correct" way, although it's not > always so pragmatic/practical. > > - What does a good framework provide for you? > > ...and the most stupid one: > > - Why are you talking about a "new framework"? Why don't we > rewrite Sinatra, Ramaze or whatever over Camping? They have > an interface that's used by others... > > > I just feel like the whole Ruby framework community stagnated a few > years after we got Rack. The moment Rack became properly implemented > everywhere it lacked any kind of > EventStream/WebSocket/long-polling-support. Everything since then has > been hacked on top. > > Rails provides ActiveRecord for database access, but more and more > stuff these days are using HTTP. I believe that a true *web* framework > should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it > (no persistant connection support in stdlib; rather > verbose/inconsistent and no cookie-jar). There are other libraries, > but these have their own conventions and limitations. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at waechter.wiz.at Wed Apr 18 13:45:57 2012 From: matthias at waechter.wiz.at (=?UTF-8?B?TWF0dGhpYXMgV8OkY2h0ZXI=?=) Date: Wed, 18 Apr 2012 15:45:57 +0200 Subject: Camping's URL mapping system In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> Message-ID: <4F8EC595.9010502@waechter.wiz.at> Am 13.04.2012 17:40, schrieb Jenna Fox: > An A4 piece of paper has a little over 9kb of data storage if storing in > binary at 300dpi A4 is about 21*30 cm?, i.e. 630 cm? or 97.65 sqin. 300 dpi means 90,000 dpsqin or about 8.788 MdpA4. Without accounting for encoding, redundancy, synchronization etc, this is about 1.1 MByte/A4 paper. If you count both sides ? 2.2 MBytes raw data. :) ? Matthias From a at creativepony.com Wed Apr 18 14:32:43 2012 From: a at creativepony.com (Jenna Fox) Date: Thu, 19 Apr 2012 00:32:43 +1000 Subject: Camping's URL mapping system In-Reply-To: <4F8EC595.9010502@waechter.wiz.at> References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F8EC595.9010502@waechter.wiz.at> Message-ID: <0DF3896B684B410EA0526591A5EC0E31@creativepony.com> Woah. Okay! I'm convinced! Lets make Rails 4.0! ? Jenna On Wednesday, 18 April 2012 at 11:45 PM, Matthias W?chter wrote: > Am 13.04.2012 17:40, schrieb Jenna Fox: > > An A4 piece of paper has a little over 9kb of data storage if storing in > > binary at 300dpi > > > > > A4 is about 21*30 cm?, i.e. 630 cm? or 97.65 sqin. 300 dpi means 90,000 > dpsqin or about 8.788 MdpA4. Without accounting for encoding, > redundancy, synchronization etc, this is about 1.1 MByte/A4 paper. If > you count both sides ? 2.2 MBytes raw data. :) > > ? Matthias > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Wed Apr 18 14:51:49 2012 From: judofyr at gmail.com (Magnus Holm) Date: Wed, 18 Apr 2012 16:51:49 +0200 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: On Wed, Apr 18, 2012 at 15:07, Daniel Bryan wrote: > Thought I'd weigh in for what it's worth, Thanks, I find it very interesting. > My naive first impression of Camping basically took no notice of the whole > 3/4k thing. I appreciate that it's a cool programming feat, and I love the > attitude that lead to it, but at the time my focus was on trying to figure > out what all these hidden instance variables you have in a controller are > (the documentation was only of sporadic use), thinking I might just dive > into the source to check it out, and obviously being confronted by the fact > that even the unabridged code is far from readable (as it wasn't intended to > be). > > I discovered Camping when I was very new to Ruby, and relatively new to > programming in general. Everyone here obviously knows the strengths and > reputation of Ruby - and projects like Camping - as a learning language. > > I've mostly moved onto working in Python, but I think there's a strong > chance that my understanding of the architecture of web applications, and > HTTP, and my motivation to understand web development at several different > layers, would have been different if Camping didn't imply a certain kind of > thinking that coloured my behaviour. Hm? What parts of Camping did this? What does Camping have in this department that e.g. Rails or Django don't? > So why not build on this? There's all sorts of amazing projects all over the > web at the moment for making programming accessible to people who are very > young, or who have literacy that's poorer than most programmers, or who live > in the third world, or who just come from subcultures / cliques where > usually you wouldn't do this kind of thing. That's cool, but as soon as > these people learn some stuff they want to do something, and they want to do > it either with mobile or the web. They google around and they find out > about, like, what? Rails? Django? What a way to turn people off. > > One of the reasons I floundered with Camping after a while is that it was > really hard to figure out where to, you know, put a lot of my code. Helpers? > I guess. This is a pretty typical problem in web frameworks, obviously - > where do you put domain-specific logic? Where do you store all your > application logic? How lightweight should your controllers be? Do you want > fat models? Heh, I find this fascinating. People desperately want the framework to have a place for everything. Just give it a good name(space) and place it in lib/. That's where all code belongs. I'm thinking of reviving lib/ for all code (controllers too!) if I ever start a framework. > I think ActiveRecord is the elephant in the room here - very quickly I ended > up using models in my apps that were just representations of the filesystem, > or of some other API, or of documents in CouchDB, or whatever. That was > cool, and Camping made that relatively easy, but the fact is I'm not an API > designer. I'm not a library writer. Any ad-hoc decision I make about how I > might model my data, as an amateurish programmer, is going to be disastrous, > but ActiveRecord just couldn't do what I wanted to do without more work than > it was worth. I agree. SQL + migrations is hard. Camping's migrations are not good enough. They should probably never have been inside the main file? > So maybe if there was some kind of Camping fork, or a new Camping-inspired > framework, or whatever, it could try to encapsulate not just this solid core > focused on using class methods as HTTP verbs, but also some kind of pattern. > What's the next thing someone needs to know after they're good with Camping? > How to write their library code. How to manage the dependencies (ugh). How > to deploy it (it took me forever to even figure out that I needed something > called a 'rackup' file - I eventually found a Heroku guide for Camping, and > even then I couldn't get it to work until I stole some code from some > project of Magnus' or Jenna's). > > I'm being incoherent, but in general I think my attraction as a novice to > Camping was for it clarity - not even necessarily its simplicity. Why not > bring that clarity to the rest of the web development process that surrounds > it? I agree with this: I'd love a framework that integrates with different tools (Bundler, RVM, rbenv) to provide the best experience. You should be able to run "bin/myapp server" and it should either work or it should give you clear instructions on how to fix it. > People keep talking about Sinatra. Personally - as a completely subjective, > essentially arbitrary position - I don't like Sinatra. Whatever you think of > it, I think it's possible to point out that we don't need to just look > inside the Ruby environment. Why not look at other places where interesting > things are happening? Node's "Express" framework, for instance, bears a lot > of similarity to Sinatra and Camping; the "Connect" middleware framework > that it uses is similar to Rack in many ways. The difference is that their > community actually brags about it, and makes a point of how much easier your > life could be if you use it for lots of stuff. It looks like there was > similar excitement about Rack back in the day, but it doesn't come across > that way so much. Maybe just because of the shadow of Rails hanging over > everything. It's just like when we bragged about Rack while the Python guys where like "duh, it's just a cool abstraction, not mind-blowing or anything". Most of the time I see people bragging about some technology it just seems that they've reinvented something. But yeah, I think there's plenty to learn from Node.js. Not to forget Perl (who would have thought that?) which currently has the best web framework I've ever seen: http://mojolicio.us/ > Sorry for ranting a little - I keep reading this thread on the way to work > and wanting to comment but not having time. In summary - I'm greatful for > what Camping provided me as a learning environment, but I think it could go > a lot further in supporting the growth of developers who used it, and > helping them to do stuff 'correctly' outside of their controllers. > > It's obvious that sockets and so on excite a lot of young programmers - > especially as so many of them have JavaScript as their first language now, > but I can't imagine how you'd support something like that properly in > something like Camping without building it on top of an event-driven > framework. Exactly. From _ at whats-your.name Wed Apr 18 14:59:50 2012 From: _ at whats-your.name (cdr) Date: Wed, 18 Apr 2012 14:59:50 +0000 Subject: framework size, forking etc. In-Reply-To: References: Message-ID: <20120418145950.GA1839@s.clearwire-wmx.net> # Sorry for ranting a little all very interesting # even the unabridged code is far from readable # I think my attraction as a novice to Camping was for its clarity these two things are inconsistent? but this brings it around: # I'm being incoherent # quickly I ended up using models in my apps that were just representations of the filesystem, or of some other API, or of documents in CouchDB yep, to me a 'model' at request time is always based on inside some CSV or JSON file, an Email, an IRC log, something curl piped to a file in a script run by cron the notion that you'll be writing new ruby Classes for each class of resource in th datamodel, and new "routes", and "migrations" to prime DB tables seems fundamentally crazy to me, and with rails' mindtrain it was copied on sinatra,camping,merb,ramaze # I've mostly moved onto working in Python i tired of ruby around 2007 after writing the webserver i actually wanted, rather than the "framework" i didnt want. it is baroque for the possibility of a runtime type-error failure to even exist. with type-inference, your Haskell or OCaml code is not more verbose than Ruby. i still maintain my webserver since it works fine but i'd never start a new project in ruby at this point # their community actually brags about it, and makes a point of how much easier your life could be if you use it the Rails community did this quite a bit too. all the alphabloggers like Ezra/Tom/court8nay and countless HN/Reddit mobs. i think it ties into human psychology of self-apprised status somehow, but it is just silliness, like obsessing about getting into a "VIP Room" at a club > Rack does seem to be increasingly a source of pain. The guardians of the > rack spec haven't done a good job keeping up with new tech. Rack is really simple, in goes a Hash of request environment, out goes a status-number, response environment + body. essentially thats what HTTP is. after making handlers for ebb, flow, mongrel, it was nice to delete all that code and just write a rack handler - they were all so similar anyways as for streaming, i was able to trivially implement 'tail -f' using rack [0] am interested in hearing what your thoughts on how Rack should change [0] http://gitorious.org/element/element/blobs/master/ruby/W/tail.rb From deveritt at innotts.co.uk Wed Apr 18 15:01:50 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 18 Apr 2012 16:01:50 +0100 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: <49D4F80C-874C-4625-9E97-0CC457EE2B8A@innotts.co.uk> Daniel - that's a great reply and echoes much of my own experience (although my Camping is much more on the tinkering side). The point about Camping being an educational tool is a good one, which I've even tried to apply to students (unsuccessfully - but that's my problem), and it would be nice to see Camping as the next step after the nicely- redesigned 'Try Ruby' - DaveE > Thought I'd weigh in for what it's worth, > > My naive first impression of Camping basically took no notice of the > whole 3/4k thing. I appreciate that it's a cool programming feat, > and I love the attitude that lead to it, but at the time my focus > was on trying to figure out what all these hidden instance variables > you have in a controller are (the documentation was only of sporadic > use), thinking I might just dive into the source to check it out, > and obviously being confronted by the fact that even the unabridged > code is far from readable (as it wasn't intended to be). > > I discovered Camping when I was very new to Ruby, and relatively new > to programming in general. Everyone here obviously knows the > strengths and reputation of Ruby - and projects like Camping - as a > learning language. > > I've mostly moved onto working in Python, but I think there's a > strong chance that my understanding of the architecture of web > applications, and HTTP, and my motivation to understand web > development at several different layers, would have been different > if Camping didn't imply a certain kind of thinking that coloured my > behaviour. > > So why not build on this? There's all sorts of amazing projects all > over the web at the moment for making programming accessible to > people who are very young, or who have literacy that's poorer than > most programmers, or who live in the third world, or who just come > from subcultures / cliques where usually you wouldn't do this kind > of thing. That's cool, but as soon as these people learn some stuff > they want to do something, and they want to do it either with mobile > or the web. They google around and they find out about, like, what? > Rails? Django? What a way to turn people off. > > One of the reasons I floundered with Camping after a while is that > it was really hard to figure out where to, you know, put a lot of my > code. Helpers? I guess. This is a pretty typical problem in web > frameworks, obviously - where do you put domain-specific logic? > Where do you store all your application logic? How lightweight > should your controllers be? Do you want fat models? > > I think ActiveRecord is the elephant in the room here - very quickly > I ended up using models in my apps that were just representations of > the filesystem, or of some other API, or of documents in CouchDB, or > whatever. That was cool, and Camping made that relatively easy, but > the fact is I'm not an API designer. I'm not a library writer. Any > ad-hoc decision I make about how I might model my data, as an > amateurish programmer, is going to be disastrous, but ActiveRecord > just couldn't do what I wanted to do without more work than it was > worth. > > So maybe if there was some kind of Camping fork, or a new Camping- > inspired framework, or whatever, it could try to encapsulate not > just this solid core focused on using class methods as HTTP verbs, > but also some kind of pattern. What's the next thing someone needs > to know after they're good with Camping? How to write their library > code. How to manage the dependencies (ugh). How to deploy it (it > took me forever to even figure out that I needed something called a > 'rackup' file - I eventually found a Heroku guide for Camping, and > even then I couldn't get it to work until I stole some code from > some project of Magnus' or Jenna's). > > I'm being incoherent, but in general I think my attraction as a > novice to Camping was for it clarity - not even necessarily its > simplicity. Why not bring that clarity to the rest of the web > development process that surrounds it? > > People keep talking about Sinatra. Personally - as a completely > subjective, essentially arbitrary position - I don't like Sinatra. > Whatever you think of it, I think it's possible to point out that we > don't need to just look inside the Ruby environment. Why not look at > other places where interesting things are happening? Node's > "Express" framework, for instance, bears a lot of similarity to > Sinatra and Camping; the "Connect" middleware framework that it uses > is similar to Rack in many ways. The difference is that their > community actually brags about it, and makes a point of how much > easier your life could be if you use it for lots of stuff. It looks > like there was similar excitement about Rack back in the day, but it > doesn't come across that way so much. Maybe just because of the > shadow of Rails hanging over everything. > > Sorry for ranting a little - I keep reading this thread on the way > to work and wanting to comment but not having time. In summary - I'm > greatful for what Camping provided me as a learning environment, but > I think it could go a lot further in supporting the growth of > developers who used it, and helping them to do stuff 'correctly' > outside of their controllers. > > It's obvious that sockets and so on excite a lot of young > programmers - especially as so many of them have JavaScript as their > first language now, but I can't imagine how you'd support something > like that properly in something like Camping without building it on > top of an event-driven framework. > > > On Wed, Apr 18, 2012 at 10:35 AM, Jenna Fox > wrote: > Those are all great points - the eventstream support is a particular > sticking point to me. It feels like a standard which aught to be > easily implemented - even through rack! but I've yet to see any web > frameworks where eventstream doesn't seem like a total hack - except > perhaps for Node.JS where the http server class is so low level > anything seems equally easy. I'm not yet convinced WebSocket is > useful for very much - it's not well supported in http servers and > reverse http proxies, and it's full-duplex nature seems unnecessary > when ajax is good enough for responding in most situations. On the > other hand, websockets doesn't even pretend to be anything like a > http request aside from setup negotiation, so there's no implication > that a web framework designed for serving pages should really have > anything to do with websocket - much of the websocket standards > specify outputting strings which look like http, but not really > parsing http headers properly or anything. > > I'd love to see some inventive solutions to long polling and event > stream. Rack does seem to be increasingly a source of pain. The > guardians of the rack spec haven't done a good job keeping up with > new tech. > > All your other points, I totally agree. Especially regexp routes. I > feel like the camping feature for generating routes from controller > names is not as good as just having a friendly route language. > > One thing I never liked about rails was having routes in a separate > file somewhere, then just some controllers named whatever files. I > wonder if the controller routes couldn't also be the controller's > filenames? I guess some operating systems wouldn't much like > filenames with forward slashes in them though (windows..) > > ? > Jenna > > On Wednesday, 18 April 2012 at 6:15 AM, Magnus Holm wrote: > >> On Mon, Apr 16, 2012 at 22:27, Nokan Emiro >> wrote: >>>> >>>> For now I'm feeling like a pretty bad "maintainer". I'm not using >>>> Camping enough to see where things need to be fixed, I'm crappy at >>>> actually shipping stuff, and I'm not sure if I believe that >>>> Camping is >>>> a correct starting point for a new framework. >>> >>> Like so many times before, I have a few silly questions again: >> >> There's no silly questions; just puzzled people who don't dare to >> ask :-) >> >>> - Why do you think so that Camping isn't a good starting point? >> >> I like centralized routing (config/routes.rb vs having routes in the >> controllers). It's also easier to combine a Sinatra-style-framework >> with centralized routing: just allow routing to a block, and `get "/" >> do ? end` is as natural as `routes.get "/", :to => "home#index"`. >> >> I prefer Sinatra-style routes over regexps. >> >> Camping's module magic is just plain bad style. Inheritance is easier >> to work with. >> >> Mapping one URL to one class is a little too verbose for me; I end up >> with tons of classes and it's hard to see which classes that actually >> work on the same type of data. For controller classes, Rails-style is >> more pragmatic. >> >> It's just 4k; that's hardly any starting point at all :-) >> >>> - What is the problem with Camping in your opinion? >> >> There's not a "problem" with Camping. It's an elegant piece of code; >> it solves HTTP in a surprisingly "correct" way, although it's not >> always so pragmatic/practical. >> >>> - What does a good framework provide for you? >>> >>> ...and the most stupid one: >>> >>> - Why are you talking about a "new framework"? Why don't we >>> rewrite Sinatra, Ramaze or whatever over Camping? They have >>> an interface that's used by others... >> >> I just feel like the whole Ruby framework community stagnated a few >> years after we got Rack. The moment Rack became properly implemented >> everywhere it lacked any kind of >> EventStream/WebSocket/long-polling-support. Everything since then has >> been hacked on top. >> >> Rails provides ActiveRecord for database access, but more and more >> stuff these days are using HTTP. I believe that a true *web* >> framework >> should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it >> (no persistant connection support in stdlib; rather >> verbose/inconsistent and no cookie-jar). There are other libraries, >> but these have their own conventions and limitations. >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Wed Apr 18 15:49:26 2012 From: a at creativepony.com (Jenna Fox) Date: Thu, 19 Apr 2012 01:49:26 +1000 Subject: framework size, forking etc. In-Reply-To: <20120418145950.GA1839@s.clearwire-wmx.net> References: <20120418145950.GA1839@s.clearwire-wmx.net> Message-ID: <8A3A93DCCCF04DBB81F323CD3ACEEDA2@creativepony.com> I think the trouble with streaming over the rack interface is that it's confusing. I'm fairly good at ruby, but I'm not entirely sure how it would even work. I guess I need to run my app in a threaded web server, running every request in it's own thread? Then inside the each iterator in the response object it just sleeps until it's got more data, using some sort of global message queue object to organise messaging between all the different threads? What if I'm deploying to passenger? what about fastcgi? Does that mean one ruby process per stream? Right now I have a few thins running with a ngynix proxy. Will the proxy be okay with sending in multiple concurrent requests in to the thins or will it need to have a process per user? It's well and truly away from being the simple rack thing everyone liked. It only gets worse when you start wanting websockets - which don't fit the rack model at all (and rightly so! but they still need to be supported) In the end what I really want is to be able to return a Rack::Stream.new as the response, which will do the each magic and deal with the web server in some way where it's the server's responsibility to make sure it works - none of my concern, and where I can keep around a reference to that Stream object and send it messages. It's actually a pretty simple problem to solve, except for getting the different ruby servers to implement one common standard on how to deal with ruby apps which have lots of long running connections open. Maybe it could be made to work somewhat okay, but I cannot imagine in my head having ten thousand sleeping threads open waiting for something to stream out is going to be very performant. There's also the Fibers and Continuations stuff which is probably about as close as we can get to a good work around for a completely artificial problem created by the rack interface. ? Jenna On Thursday, 19 April 2012 at 12:59 AM, cdr wrote: > # Sorry for ranting a little > all very interesting > > > # even the unabridged code is far from readable > # I think my attraction as a novice to Camping was for its clarity > these two things are inconsistent? but this brings it around: > # I'm being incoherent > > # quickly I ended up using models in my apps that were just representations of the filesystem, or of some other API, or of documents in CouchDB > yep, to me a 'model' at request time is always based on inside some CSV or JSON file, an Email, an IRC log, something curl piped to a file in a script run by cron > > the notion that you'll be writing new ruby Classes for each class of resource in th datamodel, and new "routes", and "migrations" to prime DB tables seems fundamentally crazy to me, and with rails' mindtrain it was copied on sinatra,camping,merb,ramaze > > # I've mostly moved onto working in Python > i tired of ruby around 2007 after writing the webserver i actually wanted, rather than the "framework" i didnt want. it is baroque for the possibility of a runtime type-error failure to even exist. with type-inference, your Haskell or OCaml code is not more verbose than Ruby. i still maintain my webserver since it works fine but i'd never start a new project in ruby at this point > > # their community actually brags about it, and makes a point of how much easier your life could be if you use it > the Rails community did this quite a bit too. all the alphabloggers like Ezra/Tom/court8nay and countless HN/Reddit mobs. i think it ties into human psychology of self-apprised status somehow, but it is just silliness, like obsessing about getting into a "VIP Room" at a club > > > Rack does seem to be increasingly a source of pain. The guardians of the > > rack spec haven't done a good job keeping up with new tech. > > > > > Rack is really simple, in goes a Hash of request environment, out goes a status-number, response environment + body. essentially thats what HTTP is. after making handlers for ebb, flow, mongrel, it was nice to delete all that code and just write a rack handler - they were all so similar anyways > > as for streaming, i was able to trivially implement 'tail -f' using rack [0] am interested in hearing what your thoughts on how Rack should change > > [0] http://gitorious.org/element/element/blobs/master/ruby/W/tail.rb > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Wed Apr 18 16:00:11 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Wed, 18 Apr 2012 17:00:11 +0100 Subject: framework size, forking etc. In-Reply-To: References: <70153F8F830646F09A2C685BDDE36524@creativepony.com> <899E84C0-CAC2-4754-A814-F89F55966EF0@innotts.co.uk> <7E0B8B5517324E5480560ECE03B00FF4@creativepony.com> <4F89820B.8060209@monnet-usa.com> <890b26a1-60bb-4d65-b9cd-2e4d7ae76011@email.android.com> Message-ID: >> Not to forget Perl (who would have thought that?) which currently >> has the best web framework I've ever seen: http://mojolicio.us/ I would have thought it - my sometimes co-developer opened my eyes to Titanium: http://mark.stosberg.com/blog/2008/12/titanium-a-new-release-and-more.html and now raves about Mojolicious. He also taught me to recognise the lie when fashionable bandwagons assert that Perl is 'old-hat' :-) DaveE From judofyr at gmail.com Wed Apr 18 16:12:49 2012 From: judofyr at gmail.com (Magnus Holm) Date: Wed, 18 Apr 2012 18:12:49 +0200 Subject: framework size, forking etc. In-Reply-To: <8A3A93DCCCF04DBB81F323CD3ACEEDA2@creativepony.com> References: <20120418145950.GA1839@s.clearwire-wmx.net> <8A3A93DCCCF04DBB81F323CD3ACEEDA2@creativepony.com> Message-ID: On Wed, Apr 18, 2012 at 17:49, Jenna Fox wrote: > I think the trouble with streaming over the rack interface is that it's > confusing. I'm fairly good at ruby, but I'm not entirely sure how it would > even work. I guess I need to run my app in a threaded web server, running > every request in it's own thread? Then inside the each iterator in the > response object it just sleeps until it's got more data, using some sort of > global message queue object to organise messaging between all the different > threads? What if I'm deploying to passenger? what about fastcgi? Does that > mean one ruby process per stream? Right now I have a few thins running with > a ngynix proxy. Will the proxy be okay with sending in multiple concurrent > requests in to the thins or will it need to have a process per user? And more importantly: How can I do I/O inside the callback without blocking the server. In this case, many servers (e.g. Thin) would only be able to serve one client at a time because you're using IO#gets which blocks the whole process (you can't use Thread.new in Thin). Also, env['async.callback'] is not a standard; different servers may support it differently (e.g. Thin only allows you to use I/O that uses EventMachine). > It's well and truly away from being the simple rack thing everyone liked. It > only gets worse when you start wanting websockets - which don't fit the rack > model at all (and rightly so! but they still need to be supported) > > In the end what I really want is to be able to return a Rack::Stream.new as > the response, which will do the each magic and deal with the web server in > some way where it's the server's responsibility to make sure it works - none > of my concern, and where I can keep around a reference to that Stream object > and send it messages. It's actually a pretty simple problem to solve, except > for getting the different ruby servers to implement one common standard on > how to deal with ruby apps which have lots of long running connections open. > Maybe it could be made to work somewhat okay, but I cannot imagine in my > head having ten thousand sleeping threads open waiting for something to > stream out is going to be very performant. There's also the Fibers and > Continuations stuff which is probably about as close as we can get to a good > work around for a completely artificial problem created by the rack > interface. Fibers and continuations doesn't solve the problem. Fibers/callcc can make callback-based code look like blocking (without actually being blocking), but it can't turn blocking into non-blocking. As long as the server assumes that #call will block until it gets a response, it's not going to handle other clients until the #call returns. From gravious at jollyrotten.org Wed Apr 25 13:26:28 2012 From: gravious at jollyrotten.org (Anthony Durity) Date: Wed, 25 Apr 2012 14:26:28 +0100 Subject: framework size, forking etc. In-Reply-To: References: <20120418145950.GA1839@s.clearwire-wmx.net> <8A3A93DCCCF04DBB81F323CD3ACEEDA2@creativepony.com> Message-ID: Hi, The reason I got into camping was because it was written by _why , because liked the way _why looked at things and approached things. Camping contains the spirit of _why , if you alter it too much it ceases to be Camping. Part of the attraction is the tiny size, the 3k/4k limit or whatever it is. A hard upper limit prevents bloat. Regarding improving/adding stuff to Camping in light that technology has moved on, is moving on. The whole reason Rack came into existence was to centralise duplicated web framework code as a middle layer. This should in theory make the web frameworks more simple, more robust. It means that if your web framework uses Rack you get all its functionality at a cost of learning a new interface. With this in mind web frameworks should still innovate and then any agreed on commonalities should migrate to Rack. Thus the question of implementing EventStream/WebSocket/long- polling-support is a question of architecting Camping to support these technologies. If it is done well in Camping then perhaps we'll be copied by other frameworks and, as I said, perhaps over time these features will migrate into Rack if it makes sense. The first two things that I added to my Camping installation were: 1) the ability to serve static files in dev mode 2) before/after handlers I think also that client side the tech is HTML/JS/CSS. Thus it actually does make sense from a symettrical and consistent point of view that if you have the inbuilt ability to spit out HTML you should have the ability to spit out JS and also CSS. Also I think it does make sense to parameterize CSS as well as JS. I see no reason why not. In short, I'd like Camping to track new developments in tech, I'd like it to gain obvious missing features, I'd like it to keep more or less the same architectural structure and code size limit _if_ possible. If not, considering that _why is no longer around I do not think that it would be appropriate to use the name he assigned his hack for a project that did not follow his ideals. Choose another name, can't be that hard, can it? Regards, Anthony On Wed, Apr 18, 2012 at 5:12 PM, Magnus Holm wrote: > On Wed, Apr 18, 2012 at 17:49, Jenna Fox wrote: > > I think the trouble with streaming over the rack interface is that it's > > confusing. I'm fairly good at ruby, but I'm not entirely sure how it > would > > even work. I guess I need to run my app in a threaded web server, running > > every request in it's own thread? Then inside the each iterator in the > > response object it just sleeps until it's got more data, using some sort > of > > global message queue object to organise messaging between all the > different > > threads? What if I'm deploying to passenger? what about fastcgi? Does > that > > mean one ruby process per stream? Right now I have a few thins running > with > > a ngynix proxy. Will the proxy be okay with sending in multiple > concurrent > > requests in to the thins or will it need to have a process per user? > > And more importantly: How can I do I/O inside the callback without > blocking the server. In this case, many servers (e.g. Thin) would only > be able to serve one client at a time because you're using IO#gets > which blocks the whole process (you can't use Thread.new in Thin). > > Also, env['async.callback'] is not a standard; different servers may > support it differently (e.g. Thin only allows you to use I/O that uses > EventMachine). > > > It's well and truly away from being the simple rack thing everyone > liked. It > > only gets worse when you start wanting websockets - which don't fit the > rack > > model at all (and rightly so! but they still need to be supported) > > > > In the end what I really want is to be able to return a Rack::Stream.new > as > > the response, which will do the each magic and deal with the web server > in > > some way where it's the server's responsibility to make sure it works - > none > > of my concern, and where I can keep around a reference to that Stream > object > > and send it messages. It's actually a pretty simple problem to solve, > except > > for getting the different ruby servers to implement one common standard > on > > how to deal with ruby apps which have lots of long running connections > open. > > Maybe it could be made to work somewhat okay, but I cannot imagine in my > > head having ten thousand sleeping threads open waiting for something to > > stream out is going to be very performant. There's also the Fibers and > > Continuations stuff which is probably about as close as we can get to a > good > > work around for a completely artificial problem created by the rack > > interface. > > Fibers and continuations doesn't solve the problem. Fibers/callcc can > make callback-based code look like blocking (without actually being > blocking), but it can't turn blocking into non-blocking. As long as > the server assumes that #call will block until it gets a response, > it's not going to handle other clients until the #call returns. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Wed Apr 25 13:48:55 2012 From: a at creativepony.com (Jenna Fox) Date: Wed, 25 Apr 2012 23:48:55 +1000 Subject: framework size, forking etc. In-Reply-To: References: <20120418145950.GA1839@s.clearwire-wmx.net> <8A3A93DCCCF04DBB81F323CD3ACEEDA2@creativepony.com> Message-ID: <7323F3F096BD489BBA819F4ABACC6578@creativepony.com> I don't think Why felt all that strongly about Camping. Anyway he's busy doing other stuff now and pretty explicitly left the project in Magnus? hands. Why may have started this whole mess, but it is Magnus who is the beloved leader. This isn't like many of Why's abandoned projects where people scrapped together sourcecode and kickstarted a DIY revival. Why handed this project off to this community long before he left the scene. The lineage is unbroken, and it is our responsibility to bring it forward (or not). If Why has any opinion on any of this he's fully welcome to let us know, but so far as I know, he has shown no opinion to date. Anyway, I agree with your priorities, but I remain in favour of a soft limit. No point building another Sinatra. We already have one of those. ? Jenna On Wednesday, 25 April 2012 at 11:26 PM, Anthony Durity wrote: > Hi, > > The reason I got into camping was because it was written by _why , because liked the way _why looked at things and approached things. Camping contains the spirit of _why , if you alter it too much it ceases to be Camping. Part of the attraction is the tiny size, the 3k/4k limit or whatever it is. A hard upper limit prevents bloat. > > Regarding improving/adding stuff to Camping in light that technology has moved on, is moving on. > > The whole reason Rack came into existence was to centralise duplicated web framework code as a middle layer. This should in theory make the web frameworks more simple, more robust. It means that if your web framework uses Rack you get all its functionality at a cost of learning a new interface. > > With this in mind web frameworks should still innovate and then any agreed on commonalities should migrate to Rack. Thus the question of implementing EventStream/WebSocket/long- > polling-support is a question of architecting Camping to support these technologies. If it is done well in Camping then perhaps we'll be copied by other frameworks and, as I said, perhaps over time these features will migrate into Rack if it makes sense. > > The first two things that I added to my Camping installation were: > 1) the ability to serve static files in dev mode > 2) before/after handlers > > I think also that client side the tech is HTML/JS/CSS. Thus it actually does make sense from a symettrical and consistent point of view that if you have the inbuilt ability to spit out HTML you should have the ability to spit out JS and also CSS. Also I think it does make sense to parameterize CSS as well as JS. I see no reason why not. > > In short, I'd like Camping to track new developments in tech, I'd like it to gain obvious missing features, I'd like it to keep more or less the same architectural structure and code size limit _if_ possible. If not, considering that _why is no longer around I do not think that it would be appropriate to use the name he assigned his hack for a project that did not follow his ideals. Choose another name, can't be that hard, can it? > > Regards, > Anthony > > > On Wed, Apr 18, 2012 at 5:12 PM, Magnus Holm wrote: > > On Wed, Apr 18, 2012 at 17:49, Jenna Fox wrote: > > > I think the trouble with streaming over the rack interface is that it's > > > confusing. I'm fairly good at ruby, but I'm not entirely sure how it would > > > even work. I guess I need to run my app in a threaded web server, running > > > every request in it's own thread? Then inside the each iterator in the > > > response object it just sleeps until it's got more data, using some sort of > > > global message queue object to organise messaging between all the different > > > threads? What if I'm deploying to passenger? what about fastcgi? Does that > > > mean one ruby process per stream? Right now I have a few thins running with > > > a ngynix proxy. Will the proxy be okay with sending in multiple concurrent > > > requests in to the thins or will it need to have a process per user? > > > > And more importantly: How can I do I/O inside the callback without > > blocking the server. In this case, many servers (e.g. Thin) would only > > be able to serve one client at a time because you're using IO#gets > > which blocks the whole process (you can't use Thread.new in Thin). > > > > Also, env['async.callback'] is not a standard; different servers may > > support it differently (e.g. Thin only allows you to use I/O that uses > > EventMachine). > > > > > It's well and truly away from being the simple rack thing everyone liked. It > > > only gets worse when you start wanting websockets - which don't fit the rack > > > model at all (and rightly so! but they still need to be supported) > > > > > > In the end what I really want is to be able to return a Rack::Stream.new as > > > the response, which will do the each magic and deal with the web server in > > > some way where it's the server's responsibility to make sure it works - none > > > of my concern, and where I can keep around a reference to that Stream object > > > and send it messages. It's actually a pretty simple problem to solve, except > > > for getting the different ruby servers to implement one common standard on > > > how to deal with ruby apps which have lots of long running connections open. > > > Maybe it could be made to work somewhat okay, but I cannot imagine in my > > > head having ten thousand sleeping threads open waiting for something to > > > stream out is going to be very performant. There's also the Fibers and > > > Continuations stuff which is probably about as close as we can get to a good > > > work around for a completely artificial problem created by the rack > > > interface. > > > > Fibers and continuations doesn't solve the problem. Fibers/callcc can > > make callback-based code look like blocking (without actually being > > blocking), but it can't turn blocking into non-blocking. As long as > > the server assumes that #call will block until it gets a response, > > it's not going to handle other clients until the #call returns. > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Wed Apr 25 16:36:17 2012 From: gurugeekphp at gmail.com (david costa) Date: Wed, 25 Apr 2012 18:36:17 +0200 Subject: Camping + Couch DB Message-ID: Hi ! First a short update on the camping "on the fly" hosting. Everything is done and tested on the backend. We are just building the frontend (coded using camping) but we are fighting with the strange behavior of the embedded sqlite database (one of my developers is using windows and things are even less user friendly there) - this is not a big issue for the user database but mostly for users that might want to store sqlite backed up. We are getting there thou ! I have seen some traces of camping working with couchDB using ShyCouch but for an odd reason I cannot get the example working.... NoMethodError: undefined method `CouchDatabase' for ShyCouch:Module and other errors. Couchcamping gem is also based on shy couch so I guess if one doesn't work the other will be broken too .. ? I wrote to the writer of the lib but before doing more tests has anyone worked on camping + couchdb (even for a quick sample) ? If yes can you email me your working code ? In theory one good thing is that couchdb runs over http so it would be very easy to offer free database and even distribute it across two different severs. I am interested also to get some real cases with couchdb so that we might use it at work too. Thanks in advance David -------------- next part -------------- An HTML attachment was scrubbed... URL: From danbryan at gmail.com Wed Apr 25 23:42:06 2012 From: danbryan at gmail.com (Daniel Bryan) Date: Thu, 26 Apr 2012 09:42:06 +1000 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: Hi David, Unfortunately, both the ShyCouch and CouchCamping libraries are far from production ready. The former was mostly a learning project, and the latter was.. bad for many more reasons than just that. I don't think either are of any use for examples, or for something you'd try to support in your new project. However, I'm actively working on some apps where I'll be using Couch as the data store, so I'm happy to work with you on generating some better, more workable examples. I noticed that you emailed me privately about ShyCouch - sorry for not having replied yet; I'll get back to you a bit later on when I have some more time. In the meantime, IIRC Jenna has a Couch library that she used in Camping that doesn't have much bloat and is more Ruby-ish. On Thu, Apr 26, 2012 at 2:36 AM, david costa wrote: > Hi ! > First a short update on the camping "on the fly" hosting. Everything is > done and tested on the backend. We are just building the frontend (coded > using camping) but we are fighting with the strange behavior of the > embedded sqlite database (one of my developers is using windows and things > are even less user friendly there) - this is not a big issue for the user > database but mostly for users that might want to store sqlite backed up. We > are getting there thou ! > > I have seen some traces of camping working with couchDB using ShyCouch but > for an odd reason I cannot get the example working.... > > NoMethodError: undefined method `CouchDatabase' for ShyCouch:Module > > and other errors. Couchcamping gem is also based on shy couch so I guess > if one doesn't work the other will be broken too .. ? I wrote to the > writer of the lib but before doing more tests has anyone worked on camping > + couchdb (even for a quick sample) ? If yes can you email me your working > code ? > In theory one good thing is that couchdb runs over http so it would be > very easy to offer free database and even distribute it across two > different severs. I am interested also to get some real cases with > couchdb so that we might use it at work too. > > Thanks in advance > David > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzleepito at gmail.com Thu Apr 26 09:02:10 2012 From: uzleepito at gmail.com (Nokan Emiro) Date: Thu, 26 Apr 2012 11:02:10 +0200 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: Hi, In a previous thread I was declared as a newbie end user, now I'll behave like that :) If I'll use the hosting service, I'll want to be able to use mysql and not sqlite, and other experimental solutions. You can say that this is silly of me, but, as an end user, I have the right to be silly. BTW I have bad experience with sqlite. It can happen that the database becomes corrupted somehow, maybe because of not properly handled concurrent accesses, or a ctrl-c in a bad moment, I don't know. And mysql is faster too. As a silly end user I would prefer a separately existing permanency layer. This is not a problem for active record, so I really don't get it why not to use it. (It would be enough to have one database for all the users and let the databasename_tablename structured tablenames solve the rest. Actually the users don't need to know where is the data stored and how, just use the ActiceRecord API, but they need to know that it's fast enough and the data is securely stored.) I'm sorry, I know I was not really constructive... ...end users are always silly... -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Thu Apr 26 11:09:43 2012 From: deveritt at innotts.co.uk (Dave Everitt) Date: Thu, 26 Apr 2012 12:09:43 +0100 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Hi Nokan I'm a professional newbie (simply because I use and teach a wide range of stuff and only go deep when I have to :-) As I'm sure you're aware, as an embedded lightweight database SQLite makes an easily-managed default setup (as in Camping... and Django, and even within OS X and, of course... RoR), but if you need a client- server database I'd say that's beyond the test server remit and would be a whole other setup/maintenance layer for David :-) SQLite is fine for me simply because I don't need anything bigger, and I can include the db file in a git repo (don't know yet if that's easy with CouchDB - anyone?). But Couch would be my choice for on/offline data sync, and I'd probably use Jenna's chill (https://github.com/Bluebie/chill) and also revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ ). DaveE > Hi, > > In a previous thread I was declared as a newbie end user, now I'll > behave > like that :) > > If I'll use the hosting service, I'll want to be able to use mysql > and not sqlite, > and other experimental solutions. You can say that this is silly of > me, but, > as an end user, I have the right to be silly. BTW I have bad > experience > with sqlite. It can happen that the database becomes corrupted > somehow, > maybe because of not properly handled concurrent accesses, or a ctrl- > c in > a bad moment, I don't know. And mysql is faster too. As a silly > end user > I would prefer a separately existing permanency layer. This is not > a problem > for active record, so I really don't get it why not to use it. (It > would be enough > to have one database for all the users and let the > databasename_tablename > structured tablenames solve the rest. Actually the users don't need > to know > where is the data stored and how, just use the ActiceRecord API, but > they > need to know that it's fast enough and the data is securely stored.) > > I'm sorry, I know I was not really constructive... > > ...end users are always silly... From a at creativepony.com Thu Apr 26 12:55:38 2012 From: a at creativepony.com (Jenna Fox) Date: Thu, 26 Apr 2012 22:55:38 +1000 Subject: Camping + Couch DB In-Reply-To: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Message-ID: Glad you like it! Chill isn't totally feature complete, but it has the important bits I think. If you ever find yourself needing extra bits I'd love to bulk it out some more - I just haven't had a use for it lately and I've not wanted to design APIs I'm not using myself. Much of the choices were made better by dogfooding (http://en.wikipedia.org/wiki/Eating_your_own_dog_food), I feel. I've been taking a bit of a break from programming lately. I'm learning ??????????? as a productive way to take a break from all this highly logical stuff! ? Jenna On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > Hi Nokan > > I'm a professional newbie (simply because I use and teach a wide range > of stuff and only go deep when I have to :-) > > As I'm sure you're aware, as an embedded lightweight database SQLite > makes an easily-managed default setup (as in Camping... and Django, > and even within OS X and, of course... RoR), but if you need a client- > server database I'd say that's beyond the test server remit and would > be a whole other setup/maintenance layer for David :-) > > SQLite is fine for me simply because I don't need anything bigger, and > I can include the db file in a git repo (don't know yet if that's easy > with CouchDB - anyone?). > > But Couch would be my choice for on/offline data sync, and I'd > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ > ). > > DaveE > > > Hi, > > > > In a previous thread I was declared as a newbie end user, now I'll > > behave > > like that :) > > > > If I'll use the hosting service, I'll want to be able to use mysql > > and not sqlite, > > and other experimental solutions. You can say that this is silly of > > me, but, > > as an end user, I have the right to be silly. BTW I have bad > > experience > > with sqlite. It can happen that the database becomes corrupted > > somehow, > > maybe because of not properly handled concurrent accesses, or a ctrl- > > c in > > a bad moment, I don't know. And mysql is faster too. As a silly > > end user > > I would prefer a separately existing permanency layer. This is not > > a problem > > for active record, so I really don't get it why not to use it. (It > > would be enough > > to have one database for all the users and let the > > databasename_tablename > > structured tablenames solve the rest. Actually the users don't need > > to know > > where is the data stored and how, just use the ActiceRecord API, but > > they > > need to know that it's fast enough and the data is securely stored.) > > > > I'm sorry, I know I was not really constructive... > > > > ...end users are always silly... > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Thu Apr 26 14:37:19 2012 From: gurugeekphp at gmail.com (david costa) Date: Thu, 26 Apr 2012 16:37:19 +0200 Subject: Camping + Couch DB In-Reply-To: References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Message-ID: Hello Jenna, I like chill too ! Is it possible to have a simple example with db connection (I see you have this on ChillDB::Database but just wanted to get something simple to cover the username/password and/or remote couch server with a different URL than localhost) and again a very simple usage to keep a database of users and a map reduce/view to select a user by email, select all users and perhaps validate if a user already exist ? :P Thanks David On Thu, Apr 26, 2012 at 2:55 PM, Jenna Fox wrote: > Glad you like it! Chill isn't totally feature complete, but it has the > important bits I think. If you ever find yourself needing extra bits I'd > love to bulk it out some more - I just haven't had a use for it lately and > I've not wanted to design APIs I'm not using myself. Much of the choices > were made better by dogfooding, > I feel. I've been taking a bit of a break from programming lately. I'm > learning ??????????? as a productive way to take a break from all this > highly logical stuff! > > ? > Jenna > > On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > > Hi Nokan > > I'm a professional newbie (simply because I use and teach a wide range > of stuff and only go deep when I have to :-) > > As I'm sure you're aware, as an embedded lightweight database SQLite > makes an easily-managed default setup (as in Camping... and Django, > and even within OS X and, of course... RoR), but if you need a client- > server database I'd say that's beyond the test server remit and would > be a whole other setup/maintenance layer for David :-) > > SQLite is fine for me simply because I don't need anything bigger, and > I can include the db file in a git repo (don't know yet if that's easy > with CouchDB - anyone?). > > But Couch would be my choice for on/offline data sync, and I'd > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > revisit Knut Hellan's article from 2009 ( > http://knuthellan.com/2009/03/08/camping-with-couchdb/ > ). > > DaveE > > Hi, > > In a previous thread I was declared as a newbie end user, now I'll > behave > like that :) > > If I'll use the hosting service, I'll want to be able to use mysql > and not sqlite, > and other experimental solutions. You can say that this is silly of > me, but, > as an end user, I have the right to be silly. BTW I have bad > experience > with sqlite. It can happen that the database becomes corrupted > somehow, > maybe because of not properly handled concurrent accesses, or a ctrl- > c in > a bad moment, I don't know. And mysql is faster too. As a silly > end user > I would prefer a separately existing permanency layer. This is not > a problem > for active record, so I really don't get it why not to use it. (It > would be enough > to have one database for all the users and let the > databasename_tablename > structured tablenames solve the rest. Actually the users don't need > to know > where is the data stored and how, just use the ActiceRecord API, but > they > need to know that it's fast enough and the data is securely stored.) > > I'm sorry, I know I was not really constructive... > > ...end users are always silly... > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Thu Apr 26 14:38:43 2012 From: gurugeekphp at gmail.com (david costa) Date: Thu, 26 Apr 2012 16:38:43 +0200 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: Hello Daniel, thanks for your reply. Well that's all I needed to know ! I wasn't sure if it was me or the script not working on couchdb 1.2 and now I know :) Best Regards David On Thu, Apr 26, 2012 at 1:42 AM, Daniel Bryan > > > Unfortunately, both the ShyCouch and CouchCamping libraries are far from > production ready. The former was mostly a learning project, and the latter > was.. bad for many more reasons than just that. I don't think either are of > any use for examples, or for something you'd try to support in your new > project. > > However, I'm actively working on some apps where I'll be using Couch as > the data store, so I'm happy to work with you on generating some better, > more workable examples. > > I noticed that you emailed me privately about ShyCouch - sorry for not > having replied yet; I'll get back to you a bit later on when I have some > more time. > > In the meantime, IIRC Jenna has a Couch library that she used in Camping > that doesn't have much bloat and is more Ruby-ish. > > On Thu, Apr 26, 2012 at 2:36 AM, david costa wrote: > >> Hi ! >> First a short update on the camping "on the fly" hosting. Everything is >> done and tested on the backend. We are just building the frontend (coded >> using camping) but we are fighting with the strange behavior of the >> embedded sqlite database (one of my developers is using windows and things >> are even less user friendly there) - this is not a big issue for the user >> database but mostly for users that might want to store sqlite backed up. We >> are getting there thou ! >> >> I have seen some traces of camping working with couchDB using ShyCouch >> but for an odd reason I cannot get the example working.... >> >> NoMethodError: undefined method `CouchDatabase' for ShyCouch:Module >> >> and other errors. Couchcamping gem is also based on shy couch so I guess >> if one doesn't work the other will be broken too .. ? I wrote to the >> writer of the lib but before doing more tests has anyone worked on camping >> + couchdb (even for a quick sample) ? If yes can you email me your working >> code ? >> In theory one good thing is that couchdb runs over http so it would be >> very easy to offer free database and even distribute it across two >> different severs. I am interested also to get some real cases with >> couchdb so that we might use it at work too. >> >> Thanks in advance >> David >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Thu Apr 26 14:54:35 2012 From: gurugeekphp at gmail.com (david costa) Date: Thu, 26 Apr 2012 16:54:35 +0200 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: HI Nokan :) On Thu, Apr 26, 2012 at 11:02 AM, Nokan Emiro > > > If I'll use the hosting service, I'll want to be able to use mysql and not > sqlite, > and other experimental solutions. You can say that this is silly of me, > but, > as an end user, I have the right to be silly. BTW I have bad experience > with sqlite. It can happen that the database becomes corrupted somehow, > maybe because of not properly handled concurrent accesses, or a ctrl-c in > a bad moment, I don't know. And mysql is faster too. As a silly end user > I would prefer a separately existing permanency layer. This is not a > problem > for active record, so I really don't get it why not to use it. > I think you are making a very good point. If this was a paid hosting I think that going without MySQL would be pure madness. But let me try to explain: this is going to be a free, not for profit service (I won't ever make any money with it or offer a paid plan for anything). Despite this caveat users (free or not) tend to expect some level of support to be available. If you offer MySQL you need to be able to help people in some circumstances (e.g. setup, I cannot login, is not working for me etc). If you don't this would be unusable even on a free basis ! :) But another more important issue is that each application now is inside a BSD jail. The jail can also host the sqlite db without problem. If you give MySQL you need a totally separated MySQL server installed outside the jails... (It would be enough > to have one database for all the users and let the databasename_tablename > structured tablenames solve the rest. > I don't think that would be very secure :) I wouldn't want that ! > Actually the users don't need to know > where is the data stored and how, just use the ActiceRecord API, but they > need to know that it's fast enough and the data is securely stored.) > > I'm sorry, I know I was not really constructive... > > ...end users are always silly... > Oh no you are not silly. You are actually very rational but what you are saying is more relevant for paid hosting. My question to you is why would even a non professional developer (let a lone a professional one) not spend 8$ a month to get unlimited databases and HD space on Dreamhost or a similar service and rely on an experimental, free platform ? I am not sure :) So back to the topic the idea of CouchDB was mostly to experiment and get something new for me to try/play with (which was fun for the last days at least). Another big plus of CouchDB is that, as it runs over HTTP, it is really easy to give space to someone and have this physically on another server. That is interesting. It would also give a chance to users to try something new. And I think this should be the spirit: to be able to try something quickly but not to replace a more stable, paid hosting with support etc. With Heroku, EngineYard and even free EC2 instances is not easy to offer something interesting. I don't really want to compete with the paid hosting that, rightly so, have to make a living out of this. The ground idea is and remain to let people try camping :) it is not my fault if Sqlite is the default embedded database on camping! On another note SQLite is not so bad. I did write a PHP wrapping for it a long time ago with encryption support etc. (http://sqlite.biz) and I never had an issue. In the wrapping I also had a secure backup method and other things to get sure that you have good copies and check integrity of the DB before running big operations. But Sqlite isn to so new now so I am trying to experiment new things like couchdb. I have also resurrected the old ruby plain file DB KirbyBase and added some camping example in the gem (that now works with ruby 1.8 and 1.9 too) https://github.com/gurugeek/KirbyBase/tree/master/examples/camping_example -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Thu Apr 26 15:00:22 2012 From: gurugeekphp at gmail.com (david costa) Date: Thu, 26 Apr 2012 17:00:22 +0200 Subject: Camping + Couch DB In-Reply-To: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Message-ID: > > > > As I'm sure you're aware, as an embedded lightweight database SQLite makes > an easily-managed default setup (as in Camping... and Django, and even > within OS X and, of course... RoR), but if you need a client-server > database I'd say that's beyond the test server remit and would be a whole > other setup/maintenance layer for David :-) > Right ! :) Of course if some of the camping people from the mailing list need MySQL I will be happy to provide some accounts (with no guarantee or support thou :P ) but the idea to upload on a run on the fly only works if you can provide with the db file together with the app. If you have to upload a dump into MySQL first you need a separate account, login etc. seems like an extra complexity. I am not ruling this out completely but if I could do without it ..it might save some time. > > SQLite is fine for me simply because I don't need anything bigger, and I > can include the db file in a git repo (don't know yet if that's easy with > CouchDB - anyone?). > Well CouchDB is just running over HTTP so it is fairly easy to handle from my tests but I don't think you can work it it as Sqlite that is embedded. Kirbybase works the same way with the plus that you can open the db file and add entries, modify etc as you please and is entirely made on ruby. With indexes it is pretty fast for me as it loads a lot of stuff in the memory. > > But Couch would be my choice for on/offline data sync, and I'd probably > use Jenna's chill (https://github.com/Bluebie/**chill) > and also revisit Knut Hellan's article from 2009 ( > http://knuthellan.com/2009/**03/08/camping-with-couchdb/ > ). > > Thanks a lot for this Dave I did not know about chill but looks very interesting and will try it today :) Best Regards David > DaveE > > > Hi, >> >> In a previous thread I was declared as a newbie end user, now I'll behave >> like that :) >> >> If I'll use the hosting service, I'll want to be able to use mysql and >> not sqlite, >> and other experimental solutions. You can say that this is silly of me, >> but, >> as an end user, I have the right to be silly. BTW I have bad experience >> with sqlite. It can happen that the database becomes corrupted somehow, >> maybe because of not properly handled concurrent accesses, or a ctrl-c in >> a bad moment, I don't know. And mysql is faster too. As a silly end user >> I would prefer a separately existing permanency layer. This is not a >> problem >> for active record, so I really don't get it why not to use it. (It would >> be enough >> to have one database for all the users and let the databasename_tablename >> structured tablenames solve the rest. Actually the users don't need to >> know >> where is the data stored and how, just use the ActiceRecord API, but they >> need to know that it's fast enough and the data is securely stored.) >> >> I'm sorry, I know I was not really constructive... >> >> ...end users are always silly... >> > > ______________________________**_________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/**listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Thu Apr 26 15:47:22 2012 From: a at creativepony.com (Jenna Fox) Date: Fri, 27 Apr 2012 01:47:22 +1000 Subject: Camping + Couch DB In-Reply-To: References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Message-ID: <3A11A926975A42D7AD8ED03A8D3EFDB9@creativepony.com> Sure. To connect chilldb using a username and password: ChillDB.goes :CakeTown, user: 'david', password: 'hackerbats' To connect it to a remote server: ChillDB.goes :YellowBrickRoad, host: 'davidcosta.camping.io' You can combine those to level up, and even add a port setting if you like! To make a database with some users you could do this: ChillDB.goes :FunkyTown # make a little template for our citizens - this doesn't do anything to the server, it's just in ChillDB's memory FunkyTown.templates( # creates a citizen template - note that an extra property - kind: 'citizen' is implied unless you specify otherwise, for convenience when writing views citizen: { name: unknown, email: nil } ) # add a design with a view to get citizens via their emails # you only need to run this once to setup the site - it stores it to the server # it doesn't matter if you run it whenever you restart the servers though - it just means couchdb has to recompute the views, which maybe a bit slow on sites with lots of documents FunkyTown.design(:citizens).views( # for all the documents which have a 'kind' value of 'citizen' and have an email set, we list them in the by_email view by_email: %q(function(thing) { if (thing.kind == "citizen" && thing.email) emit(thing.email, thing); }) ) # add some people people = ['david', 'daniel', 'nokan', 'dave', 'jenna', 'magnus'] people.each do |person| FunkyTown.template(:citizen).merge!(name: person, email: "#{person}@camping.io").commit! end # lookup magnus via his email magnus = FunkyTown.template(:citizens).query(:by_email, key: 'magnus at camping.io') couchdb is a simple thing, so if you need the ability to select all users, you do that by making another view which lists all the documents where document.kind == 'citizen' for this example. There's no magic way to do those sorts of queries - you need to tell the database in advance. CouchDB does actually have a facility for creating 'temporary views' - but chill doesn't implement it and couchdb guys explain in harsh words in their docs that it's not for use in production environments - it's just for playing around testing views before you're sure what you want. CouchDB has a nice little web interface (like a pretty and simple phpmyadmin) built right in where you can try out views like that, so I didn't see the need to have it in chill. CouchDB also has a special all_docs thing you can load, which is basically a view with everything in it. This way you can just do normal select, find, map, reduce, etc, with normal ruby arrays and things, if your data set is small enough that you don't need all of this stuff cached in the database itself. Chill doesn't do conflict validation, and it shouldn't. CouchDB doesn't work that way. You don't avoid trouble by validating that a user doesn't exist then creating them, you avoid trouble by making sure that when you look up a user and find there is two of them, you have some way to merge them or flag it up for an admin to fix. Once you have more than one database server or more than one web server process, you can't depend on the database keeping things like that sane for you. You could check the user doesn't exist yet, then another server could check, create the user, then you create the user also, and now there's two of them. It's good for the web ui to try and block this stuff - it just can't be guaranteed without making huge sacrifices to concurrency. As CouchDB can run in a p2p structure (masterless) there's no single database you can talk to who can make promises like that, and databases can even run disconnected from each other then sync up later - neat for mobiles and the likes. ? Jenna On Friday, 27 April 2012 at 12:37 AM, david costa wrote: > Hello Jenna, > I like chill too ! > Is it possible to have a simple example with db connection (I see you have this on ChillDB::Database but just wanted to get something simple to cover the username/password and/or remote couch server with a different URL than localhost) > > and again a very simple usage to keep a database of users and a map reduce/view to select a user by email, select all users and perhaps validate if a user already exist ? :P > Thanks > David > > > On Thu, Apr 26, 2012 at 2:55 PM, Jenna Fox wrote: > > Glad you like it! Chill isn't totally feature complete, but it has the important bits I think. If you ever find yourself needing extra bits I'd love to bulk it out some more - I just haven't had a use for it lately and I've not wanted to design APIs I'm not using myself. Much of the choices were made better by dogfooding (http://en.wikipedia.org/wiki/Eating_your_own_dog_food), I feel. I've been taking a bit of a break from programming lately. I'm learning ??????????? as a productive way to take a break from all this highly logical stuff! > > > > ? > > Jenna > > > > > > On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > > > > > Hi Nokan > > > > > > I'm a professional newbie (simply because I use and teach a wide range > > > of stuff and only go deep when I have to :-) > > > > > > As I'm sure you're aware, as an embedded lightweight database SQLite > > > makes an easily-managed default setup (as in Camping... and Django, > > > and even within OS X and, of course... RoR), but if you need a client- > > > server database I'd say that's beyond the test server remit and would > > > be a whole other setup/maintenance layer for David :-) > > > > > > SQLite is fine for me simply because I don't need anything bigger, and > > > I can include the db file in a git repo (don't know yet if that's easy > > > with CouchDB - anyone?). > > > > > > But Couch would be my choice for on/offline data sync, and I'd > > > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > > > revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ > > > ). > > > > > > DaveE > > > > > > > Hi, > > > > > > > > In a previous thread I was declared as a newbie end user, now I'll > > > > behave > > > > like that :) > > > > > > > > If I'll use the hosting service, I'll want to be able to use mysql > > > > and not sqlite, > > > > and other experimental solutions. You can say that this is silly of > > > > me, but, > > > > as an end user, I have the right to be silly. BTW I have bad > > > > experience > > > > with sqlite. It can happen that the database becomes corrupted > > > > somehow, > > > > maybe because of not properly handled concurrent accesses, or a ctrl- > > > > c in > > > > a bad moment, I don't know. And mysql is faster too. As a silly > > > > end user > > > > I would prefer a separately existing permanency layer. This is not > > > > a problem > > > > for active record, so I really don't get it why not to use it. (It > > > > would be enough > > > > to have one database for all the users and let the > > > > databasename_tablename > > > > structured tablenames solve the rest. Actually the users don't need > > > > to know > > > > where is the data stored and how, just use the ActiceRecord API, but > > > > they > > > > need to know that it's fast enough and the data is securely stored.) > > > > > > > > I'm sorry, I know I was not really constructive... > > > > > > > > ...end users are always silly... > > > > > > _______________________________________________ > > > Camping-list mailing list > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Thu Apr 26 15:56:05 2012 From: a at creativepony.com (Jenna Fox) Date: Fri, 27 Apr 2012 01:56:05 +1000 Subject: Camping + Couch DB In-Reply-To: References: Message-ID: <3B7B8EC3E0A945B1A2321237A7DE28D8@creativepony.com> I wonder if you were running SQLite on a linux server which stored your files on a remotely linked drive? Some large hosting companies (mediatemple is a great example) link in your files over NFS or other network filesystems, and those can often be a little buggy with regard to file locking. It's no big deal, until you have two servers trying to edit the sqlite db at the same time. That can cause corruption, but there's not really anything the sqlite db guys can do except say not to run it on network drives with buggy file locking. We wouldn't have that problem on camping's hosting. SQLite is used for everything from ruby webapps to storing the address book and notes on an iPod Touch. It's really wide spread and robust. There are almost certainly more instances of sqlite running in the world at any time than oracle, postgres, mysql, combined! I'd bet the email client I'm using to write this is storing my emails in an sqlite database. :) ? Jenna On Thursday, 26 April 2012 at 7:02 PM, Nokan Emiro wrote: > Hi, > > In a previous thread I was declared as a newbie end user, now I'll behave > like that :) > > If I'll use the hosting service, I'll want to be able to use mysql and not sqlite, > and other experimental solutions. You can say that this is silly of me, but, > as an end user, I have the right to be silly. BTW I have bad experience > with sqlite. It can happen that the database becomes corrupted somehow, > maybe because of not properly handled concurrent accesses, or a ctrl-c in > a bad moment, I don't know. And mysql is faster too. As a silly end user > I would prefer a separately existing permanency layer. This is not a problem > for active record, so I really don't get it why not to use it. (It would be enough > to have one database for all the users and let the databasename_tablename > structured tablenames solve the rest. Actually the users don't need to know > where is the data stored and how, just use the ActiceRecord API, but they > need to know that it's fast enough and the data is securely stored.) > > I'm sorry, I know I was not really constructive... > > ...end users are always silly... > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Thu Apr 26 15:59:42 2012 From: a at creativepony.com (Jenna Fox) Date: Fri, 27 Apr 2012 01:59:42 +1000 Subject: Camping + Couch DB In-Reply-To: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> Message-ID: <8FDD03AE22784E9988CC8F6B352C05AA@creativepony.com> So far as uploading a couchdb to a git repository - You could probably find the files somewhere in your system and do that, but it sounds like a bad idea. Better: use wget to download the all_docs page, backing up all the documents on that database in to a single file. Then you can restore it by wget posting it to a new server, effectively doing a bulk commit. Quick, easy, readable text file containing json and newlines IIRC. It might take some tinkering to get it to include your design documents too, but if you're chillin' you can just rerun the file which updates them to recreate those. ? Jenna On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > Hi Nokan > > I'm a professional newbie (simply because I use and teach a wide range > of stuff and only go deep when I have to :-) > > As I'm sure you're aware, as an embedded lightweight database SQLite > makes an easily-managed default setup (as in Camping... and Django, > and even within OS X and, of course... RoR), but if you need a client- > server database I'd say that's beyond the test server remit and would > be a whole other setup/maintenance layer for David :-) > > SQLite is fine for me simply because I don't need anything bigger, and > I can include the db file in a git repo (don't know yet if that's easy > with CouchDB - anyone?). > > But Couch would be my choice for on/offline data sync, and I'd > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ > ). > > DaveE > > > Hi, > > > > In a previous thread I was declared as a newbie end user, now I'll > > behave > > like that :) > > > > If I'll use the hosting service, I'll want to be able to use mysql > > and not sqlite, > > and other experimental solutions. You can say that this is silly of > > me, but, > > as an end user, I have the right to be silly. BTW I have bad > > experience > > with sqlite. It can happen that the database becomes corrupted > > somehow, > > maybe because of not properly handled concurrent accesses, or a ctrl- > > c in > > a bad moment, I don't know. And mysql is faster too. As a silly > > end user > > I would prefer a separately existing permanency layer. This is not > > a problem > > for active record, so I really don't get it why not to use it. (It > > would be enough > > to have one database for all the users and let the > > databasename_tablename > > structured tablenames solve the rest. Actually the users don't need > > to know > > where is the data stored and how, just use the ActiceRecord API, but > > they > > need to know that it's fast enough and the data is securely stored.) > > > > I'm sorry, I know I was not really constructive... > > > > ...end users are always silly... > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Thu Apr 26 16:00:59 2012 From: a at creativepony.com (Jenna Fox) Date: Fri, 27 Apr 2012 02:00:59 +1000 Subject: Camping + Couch DB In-Reply-To: <3A11A926975A42D7AD8ED03A8D3EFDB9@creativepony.com> References: <37074C72-0A30-470B-B8B5-AC9A694AA0E1@innotts.co.uk> <3A11A926975A42D7AD8ED03A8D3EFDB9@creativepony.com> Message-ID: <9C12F816A6C247C3B22C2F2F2161B572@creativepony.com> Sorry correction - the argument to ChillDB for setting your password is pass: 'hackerbats', not password: 'hackerbats'. Silly me! Maybe chill should accept both! ? Jenna On Friday, 27 April 2012 at 1:47 AM, Jenna Fox wrote: > Sure. To connect chilldb using a username and password: > > ChillDB.goes :CakeTown, user: 'david', password: 'hackerbats' > > To connect it to a remote server: > ChillDB.goes :YellowBrickRoad, host: 'davidcosta.camping.io (http://davidcosta.camping.io)' > > You can combine those to level up, and even add a port setting if you like! > > To make a database with some users you could do this: > ChillDB.goes :FunkyTown > > # make a little template for our citizens - this doesn't do anything to the server, it's just in ChillDB's memory > FunkyTown.templates( > # creates a citizen template - note that an extra property - kind: 'citizen' is implied unless you specify otherwise, for convenience when writing views > citizen: { > name: unknown, > email: nil > } > ) > > # add a design with a view to get citizens via their emails > # you only need to run this once to setup the site - it stores it to the server > # it doesn't matter if you run it whenever you restart the servers though - it just means couchdb has to recompute the views, which maybe a bit slow on sites with lots of documents > FunkyTown.design(:citizens).views( > # for all the documents which have a 'kind' value of 'citizen' and have an email set, we list them in the by_email view > by_email: %q(function(thing) { > if (thing.kind == "citizen" && thing.email) emit(thing.email, thing); > }) > ) > > # add some people > people = ['david', 'daniel', 'nokan', 'dave', 'jenna', 'magnus'] > people.each do |person| > FunkyTown.template(:citizen).merge!(name: person, email: "#{person}@camping.io (http://camping.io)").commit! > end > > # lookup magnus via his email > magnus = FunkyTown.template(:citizens).query(:by_email, key: 'magnus at camping.io (mailto:magnus at camping.io)') > > couchdb is a simple thing, so if you need the ability to select all users, you do that by making another view which lists all the documents where document.kind == 'citizen' for this example. There's no magic way to do those sorts of queries - you need to tell the database in advance. CouchDB does actually have a facility for creating 'temporary views' - but chill doesn't implement it and couchdb guys explain in harsh words in their docs that it's not for use in production environments - it's just for playing around testing views before you're sure what you want. CouchDB has a nice little web interface (like a pretty and simple phpmyadmin) built right in where you can try out views like that, so I didn't see the need to have it in chill. > > CouchDB also has a special all_docs thing you can load, which is basically a view with everything in it. This way you can just do normal select, find, map, reduce, etc, with normal ruby arrays and things, if your data set is small enough that you don't need all of this stuff cached in the database itself. > > Chill doesn't do conflict validation, and it shouldn't. CouchDB doesn't work that way. You don't avoid trouble by validating that a user doesn't exist then creating them, you avoid trouble by making sure that when you look up a user and find there is two of them, you have some way to merge them or flag it up for an admin to fix. Once you have more than one database server or more than one web server process, you can't depend on the database keeping things like that sane for you. You could check the user doesn't exist yet, then another server could check, create the user, then you create the user also, and now there's two of them. It's good for the web ui to try and block this stuff - it just can't be guaranteed without making huge sacrifices to concurrency. As CouchDB can run in a p2p structure (masterless) there's no single database you can talk to who can make promises like that, and databases can even run disconnected from each other then sync up later - neat for mobiles and the likes. > > ? > Jenna > > > On Friday, 27 April 2012 at 12:37 AM, david costa wrote: > > > Hello Jenna, > > I like chill too ! > > Is it possible to have a simple example with db connection (I see you have this on ChillDB::Database but just wanted to get something simple to cover the username/password and/or remote couch server with a different URL than localhost) > > > > and again a very simple usage to keep a database of users and a map reduce/view to select a user by email, select all users and perhaps validate if a user already exist ? :P > > Thanks > > David > > > > > > On Thu, Apr 26, 2012 at 2:55 PM, Jenna Fox wrote: > > > Glad you like it! Chill isn't totally feature complete, but it has the important bits I think. If you ever find yourself needing extra bits I'd love to bulk it out some more - I just haven't had a use for it lately and I've not wanted to design APIs I'm not using myself. Much of the choices were made better by dogfooding (http://en.wikipedia.org/wiki/Eating_your_own_dog_food), I feel. I've been taking a bit of a break from programming lately. I'm learning ??????????? as a productive way to take a break from all this highly logical stuff! > > > > > > ? > > > Jenna > > > > > > > > > On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > > > > > > > Hi Nokan > > > > > > > > I'm a professional newbie (simply because I use and teach a wide range > > > > of stuff and only go deep when I have to :-) > > > > > > > > As I'm sure you're aware, as an embedded lightweight database SQLite > > > > makes an easily-managed default setup (as in Camping... and Django, > > > > and even within OS X and, of course... RoR), but if you need a client- > > > > server database I'd say that's beyond the test server remit and would > > > > be a whole other setup/maintenance layer for David :-) > > > > > > > > SQLite is fine for me simply because I don't need anything bigger, and > > > > I can include the db file in a git repo (don't know yet if that's easy > > > > with CouchDB - anyone?). > > > > > > > > But Couch would be my choice for on/offline data sync, and I'd > > > > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > > > > revisit Knut Hellan's article from 2009 (http://knuthellan.com/2009/03/08/camping-with-couchdb/ > > > > ). > > > > > > > > DaveE > > > > > > > > > Hi, > > > > > > > > > > In a previous thread I was declared as a newbie end user, now I'll > > > > > behave > > > > > like that :) > > > > > > > > > > If I'll use the hosting service, I'll want to be able to use mysql > > > > > and not sqlite, > > > > > and other experimental solutions. You can say that this is silly of > > > > > me, but, > > > > > as an end user, I have the right to be silly. BTW I have bad > > > > > experience > > > > > with sqlite. It can happen that the database becomes corrupted > > > > > somehow, > > > > > maybe because of not properly handled concurrent accesses, or a ctrl- > > > > > c in > > > > > a bad moment, I don't know. And mysql is faster too. As a silly > > > > > end user > > > > > I would prefer a separately existing permanency layer. This is not > > > > > a problem > > > > > for active record, so I really don't get it why not to use it. (It > > > > > would be enough > > > > > to have one database for all the users and let the > > > > > databasename_tablename > > > > > structured tablenames solve the rest. Actually the users don't need > > > > > to know > > > > > where is the data stored and how, just use the ActiceRecord API, but > > > > > they > > > > > need to know that it's fast enough and the data is securely stored.) > > > > > > > > > > I'm sorry, I know I was not really constructive... > > > > > > > > > > ...end users are always silly... > > > > > > > > _______________________________________________ > > > > Camping-list mailing list > > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Camping-list mailing list > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 29 10:02:34 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 29 Apr 2012 20:02:34 +1000 Subject: Gone a little crazy Message-ID: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> So, I went a little crazy this weekend and did a whole bunch of things: * camping.io now renders properly in Chrome (yay! why didn't anyone tell me this was broken? evolving web standards are annoying!) * I tidied up some issues and commented on heaps of things on https://github.com/camping/camping/issues * I patched a readme to not talk about features we removed from The Camping Server * I created extensive documentation for chill - my couchdb abstraction. * I added bulk commit and delete support to chill - which should improve performance quite a bit * I added ruby views support to chill - but I haven't tested this yet. All these things seem vaguely related to camping (at least to me). Lets talk about the website! ? Jenna -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 29 10:12:39 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 29 Apr 2012 20:12:39 +1000 Subject: The Website Message-ID: <5CB6457E29514829B257650A1657088E@creativepony.com> So here we are, talking about the website again. Here's my thinking: David Costa's nearly got that neat camping app hosting thing working, which is amazingly awesome and we love him so much! People have all sorts of interesting ideas for things the camping site could do and have - lists of apps made in camping, wikis, forums, live chats where you're all a little spider in a sink and you can run around with your mouse and say things, text adventures, screencast theatres, interactive tutorials, book viewers, etc. What if we all just make a cool thing, and put it on David's cool hosting, and then we can all just run our own little sections of camping, like a little tent village with lots of homes which all have their own unique flavour. We could sort something out to have unified navigation menus, and have a simple app (or static page) to serve as the homepage, acting more as a gateway in to these other apps than anything else. We would be in charge of our own sections and it'd be awesome because we're all great at everything we do and we're all really great people! My hypothesis is many things aren't getting done with the website because we all just really can't be bothered getting consensus on the mailing list. We're impulsive creative people who just want to burst with energy and do something immediately without having to talk about it and justify it first. Consensus Democracy has worked great for the framework but maybe not for the site. What do you think? Can I get a consensus on this? ? Jenna -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Sun Apr 29 11:04:12 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 29 Apr 2012 13:04:12 +0200 Subject: Gone a little crazy In-Reply-To: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> References: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> Message-ID: camping.io is still badly broken for me on Opera 11.62, Windows XP. Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow bits aren't there, something went wrong with my screen capture tool, I guess.) -- Matma Rex From a at creativepony.com Sun Apr 29 12:01:51 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 29 Apr 2012 22:01:51 +1000 Subject: Gone a little crazy In-Reply-To: References: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> Message-ID: <222BB575501E48959715C18258BB724E@creativepony.com> Yeah I'm not even going to attempt that one. Opera is way out of my league. If you know how to fix it, I'd love the help, otherwise I'm all for opera's plan to pretend to be webkit. Maybe there's some way we can detect it and show opera a simpler website? ? Jenna On Sunday, 29 April 2012 at 9:04 PM, Bartosz Dziewo?ski wrote: > camping.io (http://camping.io) is still badly broken for me on Opera 11.62, Windows XP. > > Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow > bits aren't there, something went wrong with my screen capture tool, I > guess.) > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Sun Apr 29 12:03:16 2012 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 29 Apr 2012 14:03:16 +0200 Subject: The Website In-Reply-To: <5CB6457E29514829B257650A1657088E@creativepony.com> References: <5CB6457E29514829B257650A1657088E@creativepony.com> Message-ID: <73a359eb-35ad-4e94-850d-79f632150420@email.android.com> This would be great! I think I'm gonna host a development blog for the game I'm working on David's hosting service. But that will be a while from now so I'll create something else that's cool. PS. I'll work my ass off to have the first screencast done on tuesday! Cheers! Isak Andersson Jenna Fox skrev: So here we are, talking about the website again. Here's my thinking: David Costa's nearly got that neat camping app hosting thing working, which is amazingly awesome and we love him so much! People have all sorts of interesting ideas for things the camping site could do and have - lists of apps made in camping, wikis, forums, live chats where you're all a little spider in a sink and you can run around with your mouse and say things, text adventures, screencast theatres, interactive tutorials, book viewers, etc. What if we all just make a cool thing, and put it on David's cool hosting, and then we can all just run our own little sections of camping, like a little tent village with lots of homes which all have their own unique flavour. We could sort something out to have unified navigation menus, and have a simple app (or static page) to serve as the homepage, acting more as a gateway in to these other apps than anything else. We would be in charge of our own sections and it'd be awesome because we're all great at everything we do and we're all really great people! My hypothesis is many things aren't getting done with the website because we all just really can't be bothered getting consensus on the mailing list. We're impulsive creative people who just want to burst with energy and do something immediately without having to talk about it and justify it first. Consensus Democracy has worked great for the framework but maybe not for the site. What do you think? Can I get a consensus on this? ? Jenna Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/ki3fjboh1at1j78grodt3ognyxtbqnur6gypm4ruhg1jdusgqdzb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Sun Apr 29 12:22:52 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 29 Apr 2012 14:22:52 +0200 Subject: Gone a little crazy In-Reply-To: <222BB575501E48959715C18258BB724E@creativepony.com> References: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> <222BB575501E48959715C18258BB724E@creativepony.com> Message-ID: Well, the background doesn't display because the path to the background image (paper.png) is given incorrectly... -webkit-border-image: url("paper.png") 75 30 50 30 stretch stretch; -moz-border-image: url("paper.png") 75 30 50 30 stretch stretch; -o-border-image: url("http://whywentcamping.com/img/paper.png") 75 30 50 30 stretch stretch; You should also ensure that the text is at least readable without the background - a rule like "#subwrap>*{background-color:beige}" will do the trick (although will hide the fine texture of paper.png - to avoid this, create another small image to set as background to #subwrap>* containing just the texture). I don't know why the fonts don't display, but I'll try looking into it. -- Matma Rex 2012/4/29 Jenna Fox : > Yeah I'm not even going to attempt that one. Opera is way out of my league. > If you know how to fix it, I'd love the help, otherwise I'm all for opera's > plan to pretend to be webkit. Maybe there's some way we can detect it and > show opera a simpler website? > > ? > Jenna > > On Sunday, 29 April 2012 at 9:04 PM, Bartosz Dziewo?ski wrote: > > camping.io is still badly broken for me on Opera 11.62, Windows XP. > > Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow > bits aren't there, something went wrong with my screen capture tool, I > guess.) > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From matma.rex at gmail.com Sun Apr 29 12:47:16 2012 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 29 Apr 2012 14:47:16 +0200 Subject: Gone a little crazy In-Reply-To: References: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> <222BB575501E48959715C18258BB724E@creativepony.com> Message-ID: The fonts don't display because Opera sucks balls when it comes to text-transform. I have ran into problems with it before (when dynamically changing .style.textTransform of an field, the text displayed is not updated - testcase: http://dl.dropbox.com/u/10983006/textransformbug.html) and reported them, and that was almost a year ago now, and is still not fixed. Opera is pretty cool, but really sucks when it comes to handling bug reports, eh. You can work around this with a simple bit of JavaScript: if(window.opera) // if you're feeling like it, you could maybe somehow detect that the text is not shown correctly and check for this, instead of just detecting Opera { var lst = document.querySelectorAll('h1,h2,h3,h4,h5,h6') for(var i=0; i References: <768D5F066BB3493FB20E2F54B7E02C18@creativepony.com> <222BB575501E48959715C18258BB724E@creativepony.com> Message-ID: <8F09A5A527144568AE7BD35C1771B02E@creativepony.com> Fixed url for Opera. As for text rendering, so long as it's readable, I don't mind if it's ugly. Happy to let the Opera team fix Opera's bugs. ? Jenna On Sunday, 29 April 2012 at 10:22 PM, Bartosz Dziewo?ski wrote: > Well, the background doesn't display because the path to the > background image (paper.png) is given incorrectly... > > -webkit-border-image: url("paper.png") 75 30 50 30 stretch stretch; > -moz-border-image: url("paper.png") 75 30 50 30 stretch stretch; > -o-border-image: url("http://whywentcamping.com/img/paper.png") 75 > 30 50 30 stretch stretch; > > You should also ensure that the text is at least readable without the > background - a rule like "#subwrap>*{background-color:beige}" will do > the trick (although will hide the fine texture of paper.png - to avoid > this, create another small image to set as background to #subwrap>* > containing just the texture). > > I don't know why the fonts don't display, but I'll try looking into it. > > -- Matma Rex > > > 2012/4/29 Jenna Fox : > > Yeah I'm not even going to attempt that one. Opera is way out of my league. > > If you know how to fix it, I'd love the help, otherwise I'm all for opera's > > plan to pretend to be webkit. Maybe there's some way we can detect it and > > show opera a simpler website? > > > > ? > > Jenna > > > > On Sunday, 29 April 2012 at 9:04 PM, Bartosz Dziewo?ski wrote: > > > > camping.io (http://camping.io) is still badly broken for me on Opera 11.62, Windows XP. > > > > Screenshot: http://i.imgur.com/7YZQf.png (These weird light-yellow > > bits aren't there, something went wrong with my screen capture tool, I > > guess.) > > > > -- Matma Rex > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Sun Apr 29 13:13:00 2012 From: a at creativepony.com (Jenna Fox) Date: Sun, 29 Apr 2012 23:13:00 +1000 Subject: The Website In-Reply-To: <73a359eb-35ad-4e94-850d-79f632150420@email.android.com> References: <5CB6457E29514829B257650A1657088E@creativepony.com> <73a359eb-35ad-4e94-850d-79f632150420@email.android.com> Message-ID: <166E671AB42A42B0A015F8E0E864C1CB@creativepony.com> Most excellent news! :D ? Jenna On Sunday, 29 April 2012 at 10:03 PM, Isak Andersson wrote: > This would be great! > > I think I'm gonna host a development blog for the game I'm working on David's hosting service. But that will be a while from now so I'll create something else that's cool. > > PS. > > I'll work my ass off to have the first screencast done on tuesday! > > Cheers! > > Isak Andersson > > Jenna Fox skrev: > > So here we are, talking about the website again. > > > > Here's my thinking: > > > > David Costa's nearly got that neat camping app hosting thing working, which is amazingly awesome and we love him so much! People have all sorts of interesting ideas for things the camping site could do and have - lists of apps made in camping, wikis, forums, live chats where you're all a little spider in a sink and you can run around with your mouse and say things, text adventures, screencast theatres, interactive tutorials, book viewers, etc. > > > > What if we all just make a cool thing, and put it on David's cool hosting, and then we can all just run our own little sections of camping, like a little tent village with lots of homes which all have their own unique flavour. We could sort something out to have unified navigation menus, and have a simple app (or static page) to serve as the homepage, acting more as a gateway in to these other apps than anything el se. We would be in charge of our own sections and it'd be awesome because we're all great at everything we do and we're all really great people! > > > > My hypothesis is many things aren't getting done with the website because we all just really can't be bothered getting consensus on the mailing list. We're impulsive creative people who just want to burst with energy and do something immediately without having to talk about it and justify it first. Consensus Democracy has worked great for the framework but maybe not for the site. > > > > What do you think? Can I get a consensus on this? > > > > ? > > Jenna > > > > Get the best selection of online sites here. Click Here to check them out! > > http://click.lavabit.com/ki3fjboh1at1j78grodt3ognyxtbqnur6gypm4ruhg1jdusgqdzb/ > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurugeekphp at gmail.com Sun Apr 29 19:27:33 2012 From: gurugeekphp at gmail.com (david costa) Date: Sun, 29 Apr 2012 21:27:33 +0200 Subject: The Website In-Reply-To: <166E671AB42A42B0A015F8E0E864C1CB@creativepony.com> References: <5CB6457E29514829B257650A1657088E@creativepony.com> <73a359eb-35ad-4e94-850d-79f632150420@email.android.com> <166E671AB42A42B0A015F8E0E864C1CB@creativepony.com> Message-ID: Thank you for the kind words that are much appreciated. Thank you also for adding a lot of stuff to Chill which could be another very interesting add-on to camping and in general interested to anyone looking to try/build a project with couchDB. I think you are totally right on having sections maintained by several people and, somehow, if you want a feature or section for the site to get people to do it and not just bring on a wish list :) All the projects/sections can be easily added on a page in the official website with links to the relevant apps/sections. With the free hosting it will be quick to test/have like any camping app running live in few minutes. On Sun, Apr 29, 2012 at 3:13 PM, Jenna Fox wrote: > Most excellent news! :D > > ? > Jenna > > On Sunday, 29 April 2012 at 10:03 PM, Isak Andersson wrote: > > This would be great! > > I think I'm gonna host a development blog for the game I'm working on > David's hosting service. But that will be a while from now so I'll create > something else that's cool. > > PS. > > I'll work my ass off to have the first screencast done on tuesday! > > Cheers! > > Isak Andersson > > Jenna Fox skrev: > > So here we are, talking about the website again. > > Here's my thinking: > > David Costa's nearly got that neat camping app hosting thing working, > which is *amazingly awesome* and we love him so much! People have all > sorts of interesting ideas for things the camping site could do and have - > lists of apps made in camping, wikis, forums, live chats where you're all a > little spider in a sink and you can run around with your mouse and say > things, text adventures, screencast theatres, interactive tutorials, book > viewers, etc. > > What if we all just make a cool thing, and put it on David's cool hosting, > and then we can all just run our own little sections of camping, like a > little tent village with lots of homes which all have their own unique > flavour. We could sort something out to have unified navigation menus, and > have a simple app (or static page) to serve as the homepage, acting more as > a gateway in to these other apps than anything el se. We would be in charge > of our own sections and it'd be awesome because we're all great at > everything we do and we're all really great people! > > My hypothesis is many things aren't getting done with the website because > we all just really can't be bothered getting consensus on the mailing list. > We're impulsive creative people who just want to burst with energy and do > something immediately without having to talk about it and justify it first. > Consensus Democracy has worked great for the framework but maybe not for > the site. > > What do you think? Can I get a consensus on this? > > ? > Jenna > > Get the best selection of online sites here. Click Here to check them out! > > http://click.lavabit.com/ki3fjboh1at1j78grodt3ognyxtbqnur6gypm4ruhg1jdusgqdzb/ > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: