<div class="gmail_quote">On Thu, May 28, 2009 at 12:00 PM, Tomas Doran <span dir="ltr"><<a href="mailto:bobtfish@bobtfish.net">bobtfish@bobtfish.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sorry to let you down, but this mail was written in 2006, and contains the plan as it was then.<br>
<br>
Unfortunately, nobody has stepped up to the plate to do the requisite work to split the application class and context (which is what that mail is hinting at).</blockquote><div><br>/sadpanda :(<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The work done in 5.80 makes this _significantly_ easier than it used to be if someone wants to step up to help tackle it - I think more work is involved munging the test suite than actually hacking Catalyst itself..</blockquote>
<div><br>Hmm....well, something I might get to eventually, but probably not a project for Still-Reading-Tutorials Guy.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It _is_ still possible to have one application instance serving many vhosts, and many of the parts are there - supporting this inside your application isn't too difficult, but unfortunately you can't yet get it 'out of the box'.</blockquote>
</div><br>It seems to me it could be done almost entirely within mod_perl using some interpreter pool trickery and by deferring AppClass->setup(). I assume that is the call in the base package that instantiates everything for the Catalyst app, yes?<br>
<br>Commenting that out, then theoretically (note that this is totally untested at the moment, but I intend to tomorrow):<br><br>PerlModule AppClass<br><br><VirtualHost foo><br>PerlOptions +Clone<br>PerlSetVar catalyst_instance foo<br>
SetHandler modperl<br>PerlResponseHandler AppClass<br></VirtualHost><br><br clear="all"><VirtualHost bar><br>
PerlOptions +Clone<br>
PerlSetVar catalyst_instance bar<br>
SetHandler modperl<br>PerlResponseHandler AppClass<br>
</VirtualHost><br>
<br>And then a custom mp handler that does AppClass->setup() with an appropriate config (based on catalyst_instance) on the first request and then passes off to AppClass->handle_request. By deferring the instantiation you restrict the package globals to the virtual host's interpreter pool (so multiple apps won't collide), but still gain the optree sharing by cloning from the top-level interpreter with all the Catalyst code pre-loaded.<br>
<br>I welcome anyone crazy enough to try this before I do :)<br><br>-- <br>Stephen Clouse <<a href="mailto:stephenclouse@gmail.com">stephenclouse@gmail.com</a>><br>