Re: Mason + FastCGI

Hi,

On 2009/09/30, at 19:06, Jonathan Swartz wrote:

> That would be interesting to me, at least. I'm curious what things  
> don't work with the regular CGI handler.

Maybe I used the wrong word. Is not that it doesn't work, but Mason  
assumes that Apache will do some of the work with directory requests.

If you have a /index.html and you request the /, the standard Mason  
will not find index.html because that part is usually done by Apache  
and its DirectoryIndex directive. And yes, I know about the rewrite  
tricks that you can do but still, I would prefer a in-Mason solution.

What I did on my experimental Mason, was this:

(before you look at the code, please read the commit message. Yes,  
this is the wrong fix, it should be inside the Interp.pm code, but I  
was in a hurry at the time and this was a proof-of-concept)

http://github.com/melo/exp-mason-fcgi/commit/2360faa2c94f44b2be4f4cce6dbdcbfdbb788107

Basically if we can't find the component for the request, we will try  
to find index.html and index.htm. The names are hardcoded in this  
experiment. In a real patch, I would make that an option to the Interp  
class, something like directory_index => ['index.html', 'index.htm']


> I'm sure Dave would say, "why don't you just use Catalyst with  
> Mason"? But I expect you have a reason, given that you are obviously  
> aware of Catalyst. :)

Its a good question, but I did my homework on this one :). Basically  
Catalyst doesn't add any value to this site:

  * I don't need multiple views per controller, only straight HTML;
  * all my Model's are alteady abstracted away;
  * the URLs are pretty simple, I don't need any chaining stuff.

Besides, the development environment of Mason is much better IMHO. I  
don't have to restart the app_server.pl everytime I change stuff, only  
when the models change.

And I think that Mason has better performance on production  
environment: the component preload, and the static_source features are  
awesome.

But, even if I make a bad decision right now, and the site grows to a  
point where Cat is actually a better solution, I can still reuse all  
my Mason components as a Cat view.

So picking Mason right now has no down-side for this site.

Best regards,


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf