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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/9f955007/attachment.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/a5cbc7d1/attachment.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/aa1d3857/attachment.html>
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 <deveritt at innotts.co.uk>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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/d73ef550/attachment-0001.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/556d5f01/attachment.html>
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 > <deveritt at innotts.co.uk> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120411/91a18041/attachment.html>
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 <deveritt at innotts.co.uk>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: <http://rubyforge.org/pipermail/camping-list/attachments/20120412/783b75c3/attachment.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120412/bd42f14f/attachment.html>
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
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120412/df31b1e4/attachment-0001.html>
On Thu, Apr 12, 2012 at 15:59, Jenna Fox <a at creativepony.com> 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 servingbin/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?
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 <a at creativepony.com (mailto:a at creativepony.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120413/f5de2cb8/attachment.html>
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.
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120413/b3487c14/attachment.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/80ce8ab5/attachment-0001.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/d417dd10/attachment.html>
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 <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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120413/c2b5b53e/attachment.html>
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 <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.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120413/a8fcb6b2/attachment.html>
Yeah of course! Cheers! Isak Andersson Dave Everitt <deveritt at innotts.co.uk> 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 <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. Choose the Prize you Want to Win, Play PacMan to it! http://click.lavabit.com/ww7o34bkc7cxdk49gqcbw6x8jgi7jrtao1g6b4swpcrtko5bz8uy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120413/5ab2536b/attachment-0001.html>
On Thu, Apr 12, 2012 at 16:54, Jenna Fox <a at creativepony.com> 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 <a at creativepony.com> 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
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 <a at creativepony.com (mailto:a at creativepony.com)> 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 <a at creativepony.com (mailto:a at creativepony.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/94787744/attachment-0001.html>
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
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/9acca072/attachment.html>
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 <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 > http://rubyforge.org/mailman/listinfo/camping-list-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/e1b3e6c2/attachment.html>
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 <ruby at monnet-usa.com> 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 <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120414/fc76ea53/attachment.html>
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 <IcePapih at lavabit.com>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 <ruby at monnet-usa.com> 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 <deveritt at innotts.co.uk> <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120415/86248241/attachment-0001.html>
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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com> 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 <ruby at monnet-usa.com> 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 <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120415/96701524/attachment.html>
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 <IcePapih at lavabit.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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com>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 <ruby at monnet-usa.com> 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 <deveritt at innotts.co.uk> <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/ac965fed/attachment.html>
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 <IcePapih at lavabit.com (mailto:IcePapih at lavabit.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 <gurugeekphp at gmail.com (mailto:gurugeekphp at gmail.com)> 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 <IcePapih at lavabit.com (mailto:IcePapih at lavabit.com)> 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 <ruby at monnet-usa.com (mailto:ruby at monnet-usa.com)> 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 <deveritt at innotts.co.uk> (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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/ce547206/attachment-0001.html>
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 <IcePapih at lavabit.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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com >>>> > 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 <ruby at monnet-usa.com> 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 <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 >>>>>>> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/1850e8d8/attachment.html>
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 <a at creativepony.com> 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 <IcePapih at lavabit.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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com> 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 <ruby at monnet-usa.com> 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 <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/22500a1d/attachment.html>
On Mon, Apr 16, 2012 at 5:40 PM, Dave Everitt <deveritt at innotts.co.uk>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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/7f3e3982/attachment-0001.html>
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. :)
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 <IcePapih at lavabit.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 <a at creativepony.com> 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 <IcePapih at lavabit.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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com>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 <ruby at monnet-usa.com> 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 <deveritt at innotts.co.uk> <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 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/cd838a44/attachment-0001.html>
W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro <uzleepito at gmail.com> 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
On Sun, Apr 15, 2012 at 01:59, david costa <gurugeekphp at gmail.com> 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.
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 > <uzleepito at gmail.com> 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
2012/4/16 Bartosz Dziewo?ski <matma.rex at gmail.com>> W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro > <uzleepito at gmail.com> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/4cba7492/attachment.html>
On Mon, Apr 16, 2012 at 22:14, Nokan Emiro <uzleepito at gmail.com> wrote:> 2012/4/16 Bartosz Dziewo?ski <matma.rex at gmail.com> >> >> W dniu 16 kwietnia 2012 20:50 u?ytkownik Nokan Emiro >> <uzleepito at gmail.com> 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
> > > 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/2e200e8f/attachment-0001.html>
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 > > <uzleepito at gmail.com> 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
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/89f3c7e2/attachment.html>
> > > 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 frameworkHey 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120416/762cd429/attachment.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/cb44f93e/attachment.html>
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
+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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/d047c6f6/attachment-0001.html>
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 <IcePapih at lavabit.com>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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/d1f1449a/attachment.html>
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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/729674c8/attachment.html>
Agreed, Magnus does an amazing job with Camping! More than anyone else has done anyway. Cheers! Isak Andersson Dave Everitt <deveritt at innotts.co.uk> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/34c7b452/attachment.html>
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 <IcePapih at lavabit.com>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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com>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: <http://rubyforge.org/pipermail/camping-list/attachments/20120417/ab816180/attachment-0001.html>
On Mon, Apr 16, 2012 at 22:27, Nokan Emiro <uzleepito at gmail.com> 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.
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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com> 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 <gurugeekphp at gmail.com> 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 <IcePapih at lavabit.com> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120418/a170ce15/attachment.html>
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 <uzleepito at gmail.com (mailto:uzleepito at gmail.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120418/07dcc00b/attachment.html>
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 <a at creativepony.com> 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 <uzleepito at gmail.com> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120418/98225aa7/attachment-0001.html>
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 300dpiA4 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
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120419/1b4d1f12/attachment.html>
On Wed, Apr 18, 2012 at 15:07, Daniel Bryan <danbryan at gmail.com> 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.
# 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
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 <a at creativepony.com> > 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 <uzleepito at gmail.com> >> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120418/e25717f7/attachment-0001.html>
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: <http://rubyforge.org/pipermail/camping-list/attachments/20120419/1cc76e54/attachment.html>
>> 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
On Wed, Apr 18, 2012 at 17:49, Jenna Fox <a at creativepony.com> 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.
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 <judofyr at gmail.com> wrote:
> On Wed, Apr 18, 2012 at 17:49, Jenna Fox <a at creativepony.com>
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:
<http://rubyforge.org/pipermail/camping-list/attachments/20120425/5f015a42/attachment-0001.html>
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 <judofyr at gmail.com (mailto:judofyr at gmail.com)> wrote: > > On Wed, Apr 18, 2012 at 17:49, Jenna Fox <a at creativepony.com (mailto:a at creativepony.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20120425/6f1a8511/attachment.html>