Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Sun, Oct 14, 2012 at 2:56 PM, Tatsuhiko Miyagawa wrote: > I think Lars meant no proxy required with *mod_perl* rather than plack > stuff, but yes, Starman is recommended to put behind proxy otherwise > your precious worker process is bound to slow networked clients, and > gets even worse if you

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

- > Von: Tatsuhiko Miyagawa [mailto:miyag...@gmail.com] > Gesendet: Sonntag, 14. Oktober 2012 20:57 > An: modperl@perl.apache.org > Betreff: Re: Coupling Plack/PSGI with mod_perl, or an alternate > architecture? > > On Fri, Oct 12, 2012 at 11:59 AM, Fred Moyer wrote: >> >>

AW: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

Hi Tatsuhiko, which proxy do you use in front? Best regards McA -Ursprüngliche Nachricht- Von: Tatsuhiko Miyagawa [mailto:miyag...@gmail.com] Gesendet: Sonntag, 14. Oktober 2012 20:57 An: modperl@perl.apache.org Betreff: Re: Coupling Plack/PSGI with mod_perl, or an alternate

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Fri, Oct 12, 2012 at 11:59 AM, Fred Moyer wrote: > > - A stable history of distribution packaging. Odds are the platform > you are using has mod_perl / Apache rpms/deb/ebuilds/etc for quite > some time. These days more developers want to build (and even deploy) their own perl using tools such

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Fri, Oct 12, 2012 at 12:26 PM, Perrin Harkins wrote: > On Wed, Oct 10, 2012 at 3:57 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: >>> reasons to pick a mod_perl approach over a plack runner approach >> Requires no proxying. > > Isn't Starman normally run with a proxy in front of it? If not, it > should be. Ot

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

--- On Fri, 10/12/12, Fred Moyer wrote: > On Wed, Oct 10, 2012 at 12:39 PM, Perrin Harkins wrote: > >> 2) Do you believe that there are any compelling reasons to pick a mod_perl > >> approach over a plack runner approach that we may be missing? > > > > Advantages of a mod_perl approach: > > - Acce

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Wed, Oct 10, 2012 at 3:57 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: >> reasons to pick a mod_perl approach over a plack runner approach > Requires no proxying. Isn't Starman normally run with a proxy in front of it? If not, it should be. Otherwise, you'd be tying up large processes sending bytes to slow r

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Wed, Oct 10, 2012 at 12:39 PM, Perrin Harkins wrote: >> 2) Do you believe that there are any compelling reasons to pick a mod_perl >> approach over a plack runner approach that we may be missing? > > Advantages of a mod_perl approach: > - Access to all the mod_perl stuff on CPAN (auth modules,

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

> Has anyone on this list actually run a Plack application *inside* > mod_perl? Yes. > how one does that. > relative merits of this approach? It is very similar to the way traditional mod_perl apps are deployed and therefore familiar. > reasons to pick a

Re: Coupling Plack/PSGI with mod_perl, or an alternate architecture?

On Wed, Oct 10, 2012 at 1:46 PM, Eduardo Arino de la Rubia wrote: > Greetings! Hi! > 1) Has anyone on this list actually run a Plack application *inside* > mod_perl? I don't actually know that I understand how one does that. Can you > speak to the relative merits of this approach? I think it's

Coupling Plack/PSGI with mod_perl, or an alternate architecture?

Greetings! I know this may be a biased audience, it being the mod_perl mailing list, but I since I don't have a plan, I'm trying to crowdsource one :-) At $employer, we have chosen to build our next revision of our application using a Plack/PSGI stack. We have been sold on Plack/PSGI as a "next g