mod_perl EC2 AMI"s or other platform providers?

The only public AMI for EC2 setup with mod_perl I can easily find is an
OpenSuse one from 2009.

Services like Bitnami are a really nice platform for launching LAMP
stacks, unfortunately the P is anything but Perl :(

Is there a reason for the lack of plug'n'play mod_perl LAMP cloud
service providers? Or are there a ton that I just don't know about?

Tosh

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

On 4 Jul 2011, at 11:03, Tosh Cooey wrote:

> The only public AMI for EC2 setup with mod_perl I can easily find is =
an OpenSuse one from 2009.
>=20
> Services like Bitnami are a really nice platform for launching LAMP =
stacks, unfortunately the P is anything but Perl :(
>=20
> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud =
service providers? Or are there a ton that I just don't know about?
>=20

Because you really should build your own perl, mod_perl and Apache =
stack.

Re: mod_perl EC2 AMI"s or other platform providers?

Dave Hodgkinson wrote:
> On 4 Jul 2011, at 11:03, Tosh Cooey wrote:
>
>> The only public AMI for EC2 setup with mod_perl I can easily find is an OpenSuse one from 2009.
>>
>> Services like Bitnami are a really nice platform for launching LAMP stacks, unfortunately the P is anything but Perl :(
>>
>> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud service providers? Or are there a ton that I just don't know about?
>>
>
> Because you really should build your own perl, mod_perl and Apache stack.
>
Come now.
I don't know the relevance of the above original question, nor the merits of that
particular target platform.

But who nowadays is still building their own Apache/mod_perl/perl set ?
We have about 50 Apache/mod_perl/perl servers running, in-house and at customers, on a
variety of platforms, and I cannot remember having to build any of them over the last 3-4
years at least.
Which is very sweet, because as a sysadmin and applications programmer, I really don't
feel like having to go hunting for missing dependencies, compatible versions, or outdated
definitions in some .h file.
And I don't really have the time to do that either.
And for at least some of these platforms, I don't have the knowledge to do that easily either.


Tosh,
the real answer is that all these software packages are open-source and free (as in free
beer), so creating a package for some specific platform is only done when someone
volunteers to do it (and maintain it) for that platform, and then makes it available for
others.
And I guess that this has not happened (yet) for the particular platform which you mention.
So you could probably render a service to the community by doing this, and posting the
results somewhere.
Alternatively, I guess that you could ask Amazon themselves how to go about doing that.

Re: mod_perl EC2 AMI"s or other platform providers?

Am Mo, 4.07.2011, 12:03 schrieb Tosh Cooey:
> The only public AMI for EC2 setup with mod_perl I can easily find is an
> OpenSuse one from 2009.
>
> Services like Bitnami are a really nice platform for launching LAMP
> stacks, unfortunately the P is anything but Perl :(
>
> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud
> service providers? Or are there a ton that I just don't know about?
>
> Tosh
>
> --
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
>

We run a few EC2 instances with mod_perl setup and afaik there is no
public image that gives you an out-of-the-box system. We use Debian images
by Alestic (sadly these are not updated any more but I guess one could use
their Ubuntu images instead) that give you a basic Debian setup. From
there to a working apache/mod_perl it's just a few apt-get install calls
(that can be executed automatically when running a new instance) and
deploying your application so this should be as far as you can get towards
mod_perl.

Apart from that I don't think anyone could package a mod_perl image for
you that can be used out-of-the-box at all. A usual mod_perl setup needs
certain perl-modules in place, a setup.pl, special apache-configurations
etc.

Hendrik

Re: mod_perl EC2 AMI"s or other platform providers?

On 4 Jul 2011, at 11:03, Tosh Cooey wrote:

> The only public AMI for EC2 setup with mod_perl I can easily find is =
an OpenSuse one from 2009.
>=20
> Services like Bitnami are a really nice platform for launching LAMP =
stacks, unfortunately the P is anything but Perl :(
>=20
> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud =
service providers? Or are there a ton that I just don't know about?


Glad you're happy with perl 5.8.8 and old, possibly buggy CPAN modules.

Re: mod_perl EC2 AMI"s or other platform providers?

On 7/4/11 7:54 PM, Dave Hodgkinson wrote:
>
> On 4 Jul 2011, at 11:03, Tosh Cooey wrote:
>
>> The only public AMI for EC2 setup with mod_perl I can easily find is an OpenSuse one from 2009.
>>
>> Services like Bitnami are a really nice platform for launching LAMP stacks, unfortunately the P is anything but Perl :(
>>
>> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud service providers? Or are there a ton that I just don't know about?
>
>
> Glad you're happy with perl 5.8.8 and old, possibly buggy CPAN modules.
>


I'm not happy, hence the complaining about the AMI from 2009. But I'm
glad you changed the subject from your first one, which is that I should
build my own stack.

So basically you are saying (and only you, not a community voice) that
in order to be a mod_perl developer one also needs to:

1) Build and optimize Apache.
2) Build and optimize MySql.
3) Build and optimize Perl+mod_perl.
4) Build and optimize a Linux server environment.
or
5) Have enough money to pay for all of the above.

I understand the Renaissance Man appeal, we all want to be da Vinci, but
that's hardly practical when a good dev needs to know perl, JS, some JS
library (ie. jQuery), HTML, and CSS. And let's be honest, what hot
admin who can do 1-4 above really wants to perfect their knowledge of
CSS and JS?!

And to address Herr Schumacher, of course no mod_perl environment will
be perfect, they will all need to be tweaked, but changing a startup.pl
and adding needed modules is not the same as steps 1-4 above.

You could just say, "what you complain about seems to be a hole in the
market" rather than trying to dismiss the need.

Tosh

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

On 7/4/11 12:33 PM, Dave Hodgkinson wrote:
>
> On 4 Jul 2011, at 11:03, Tosh Cooey wrote:
>
>> The only public AMI for EC2 setup with mod_perl I can easily find is an OpenSuse one from 2009.
>>
>> Services like Bitnami are a really nice platform for launching LAMP stacks, unfortunately the P is anything but Perl :(
>>
>> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud service providers? Or are there a ton that I just don't know about?
>>
>
> Because you really should build your own perl, mod_perl and Apache stack.
>


Why? Especially when that's not the direction that development
technology is moving in. It seems everything is becoming a platform.

Storage is a platform, processing power is a platform, and services like
database and email are platforms.

Python is a platform on Google, PHP is part of many platforms. I fail
to see a benefit in building your own perl, mod_perl and Apache stack.

Tosh


--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

On 4 Jul 2011, at 21:56, Tosh Cooey wrote:

> On 7/4/11 7:54 PM, Dave Hodgkinson wrote:
>>=20
>> On 4 Jul 2011, at 11:03, Tosh Cooey wrote:
>>=20
>>> The only public AMI for EC2 setup with mod_perl I can easily find is =
an OpenSuse one from 2009.
>>>=20
>>> Services like Bitnami are a really nice platform for launching LAMP =
stacks, unfortunately the P is anything but Perl :(
>>>=20
>>> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud =
service providers? Or are there a ton that I just don't know about?
>>=20
>>=20
>> Glad you're happy with perl 5.8.8 and old, possibly buggy CPAN =
modules.
>>=20
>=20
>=20
> I'm not happy, hence the complaining about the AMI from 2009. But I'm =
glad you changed the subject from your first one, which is that I should =
build my own stack.
>=20
> So basically you are saying (and only you, not a community voice) that =
in order to be a mod_perl developer one also needs to:
>=20
> 1) Build and optimize Apache.
> 2) Build and optimize MySql.
> 3) Build and optimize Perl+mod_perl.
> 4) Build and optimize a Linux server environment.
> or
> 5) Have enough money to pay for all of the above.

You have no stack.

Make one.

Better still, get a bunch of people together with the same problem. =
Dunno where
you'd find 'em.

I just spent six months helping a company do exactly[0] this and move =
off a dated
RH platform onto a modern, current, Debian, perl 5.14, all new CPAN =
modules.

The developers were unleashed with modern perl and moduels and the =
admins didn't
have to worry about holding together decrepit operating systems with =
known issues.

There's a benefit.

It doesn't take that long to build a perl, load it with modules =
(especially with=20
cpanm), compile an Apache and a mod_perl.=20

As for optimize, I've always found gentoo-safe flags for the arch you're =
targetting=20
to work pretty well.

And the developers got exactly the perl they wanted: fully 64-bit =
internals. (Having
a core committer on the team helped and a few other perl world stalwarts =
besides).

Sorry to have been so blunt about it but you have a problem and have an =
issue with=20
adressing it.

[0] A small part of the six months, there was a lot of other stuff going =
on too :)

Re: mod_perl EC2 AMI"s or other platform providers?

On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>
>>
>> I'm not happy, hence the complaining about the AMI from 2009. But I'm glad you changed the subject from your first one, which is that I should build my own stack.
>>
>> So basically you are saying (and only you, not a community voice) that in order to be a mod_perl developer one also needs to:
>>
>> 1) Build and optimize Apache.
>> 2) Build and optimize MySql.
>> 3) Build and optimize Perl+mod_perl.
>> 4) Build and optimize a Linux server environment.
>> or
>> 5) Have enough money to pay for all of the above.
>
> You have no stack.
>
> Make one.
>
> Better still, get a bunch of people together with the same problem. Dunno where
> you'd find 'em.
>
> I just spent six months helping a company do exactly[0] this and move off a dated
> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN modules.


You seem to have missed the point of my kvetching, which is perhaps a
suitable answer anyway.

Thank-you.

Tosh

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

On 5 Jul 2011, at 08:53, Tosh Cooey wrote:

> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>=20
>>>=20
>>> I'm not happy, hence the complaining about the AMI from 2009. But =
I'm glad you changed the subject from your first one, which is that I =
should build my own stack.
>>>=20
>>> So basically you are saying (and only you, not a community voice) =
that in order to be a mod_perl developer one also needs to:
>>>=20
>>> 1) Build and optimize Apache.
>>> 2) Build and optimize MySql.
>>> 3) Build and optimize Perl+mod_perl.
>>> 4) Build and optimize a Linux server environment.
>>> or
>>> 5) Have enough money to pay for all of the above.
>>=20
>> You have no stack.
>>=20
>> Make one.
>>=20
>> Better still, get a bunch of people together with the same problem. =
Dunno where
>> you'd find 'em.
>>=20
>> I just spent six months helping a company do exactly[0] this and move =
off a dated
>> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN =
modules.
>=20
>=20
> You seem to have missed the point of my kvetching, which is perhaps a =
suitable answer anyway.


What was the point?=

Re: mod_perl EC2 AMI"s or other platform providers?

Dave Hodgkinson wrote:
> On 5 Jul 2011, at 08:53, Tosh Cooey wrote:
>
>> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>>> I'm not happy, hence the complaining about the AMI from 2009. But I'm glad you changed the subject from your first one, which is that I should build my own stack.
>>>>
>>>> So basically you are saying (and only you, not a community voice) that in order to be a mod_perl developer one also needs to:
>>>>
>>>> 1) Build and optimize Apache.
>>>> 2) Build and optimize MySql.
>>>> 3) Build and optimize Perl+mod_perl.
>>>> 4) Build and optimize a Linux server environment.
>>>> or
>>>> 5) Have enough money to pay for all of the above.
>>> You have no stack.
>>>
>>> Make one.
>>>
>>> Better still, get a bunch of people together with the same problem. Dunno where
>>> you'd find 'em.
>>>
>>> I just spent six months helping a company do exactly[0] this and move off a dated
>>> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN modules.

Ah, the beauty of being able to
apt-get install libapache2-mod-perl2

>>
>> You seem to have missed the point of my kvetching, which is perhaps a suitable answer anyway.
>
>
> What was the point?

Rather than slinging it out in public, you may want to consider..

There are bound to be different points of view for this kind of issue, from different
kinds of users. I see the same on other forums to which I subscribe (Apache, Tomcat).
It is like a triangle.
In corner A, there are developers who want to have the latest versions of their particular
packages of interest and be able to fine-tune their setup for easy development, debugging,
bug reporting etc.., but do not care very much if other packages consequently run less
well on the same server.
In corner B are mere users, who just want the applications to work 24/24, and could not
care less about the underlying package versions as long as it does work.
And in corner C are sysadmins, who are supposed to manage an ever-increasing number of
servers, install something on request of A or B within the next 5 minutes, and then keep
all the servers up-to-date OS-wise and many-different-packages-wise over time.
Since all of them want to sleep at night and take holidays from time to time, these
different positions/requirements are bound to conflict occasionally. Depending on the
people involved, the size of the organisations, the budgets at stake etc, these groups may
overlap or not and have different weights, so the shape and point of equilibrium of the
triangle will be different in each case. And I'm sure that it's a polygon rather than a
mere triangle. There certainly isn't one answer which fits all.
Personally, I must say that statements like "I just spent six months helping a company do
exactly[0] this" make me dream. I must be in the wrong triangle...

Re: mod_perl EC2 AMI"s or other platform providers?

On 5 Jul 2011, at 10:53, Andr=E9 Warnier wrote:

> Personally, I must say that statements like "I just spent six months =
helping a company do exactly[0] this" make me dream. I must be in the =
wrong triangle...
>=20

It was an interesting dynamic. Ownership of the Apache stack moved to =
the developers,
based on their skillset. It was regarded as part of the application they =
were=20
developing.

I also got to introduce sanity to their Selenium usage but that's =
another story :)

Re: mod_perl EC2 AMI"s or other platform providers?

The point was, and is, that it's unfortunate that mod_perl developers
need to:

1) Build and optimize Apache.
2) Build and optimize MySql.
3) Build and optimize Perl+mod_perl.
4) Build and optimize a Linux server environment.
or
5) Have enough money to pay for all of the above.

Those are all roadblocks to development, much like your responses are to
this discussion.

My life would be a different experience if I could pay for six months of
your time whenever I wanted to create a new web application.

It would be nice to fire up a mod_perl stack somewhere (say EC2) and
then just modify startup.pl and install your required modules and go.

The dev world is moving away from requiring system administrators and
towards more PaaS'.

Tosh



On 7/5/11 10:48 AM, Dave Hodgkinson wrote:
>
> On 5 Jul 2011, at 08:53, Tosh Cooey wrote:
>
>> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>>
>>>>
>>>> I'm not happy, hence the complaining about the AMI from 2009. But I'm glad you changed the subject from your first one, which is that I should build my own stack.
>>>>
>>>> So basically you are saying (and only you, not a community voice) that in order to be a mod_perl developer one also needs to:
>>>>
>>>> 1) Build and optimize Apache.
>>>> 2) Build and optimize MySql.
>>>> 3) Build and optimize Perl+mod_perl.
>>>> 4) Build and optimize a Linux server environment.
>>>> or
>>>> 5) Have enough money to pay for all of the above.
>>>
>>> You have no stack.
>>>
>>> Make one.
>>>
>>> Better still, get a bunch of people together with the same problem. Dunno where
>>> you'd find 'em.
>>>
>>> I just spent six months helping a company do exactly[0] this and move off a dated
>>> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN modules.
>>
>>
>> You seem to have missed the point of my kvetching, which is perhaps a suitable answer anyway.
>
>
> What was the point?

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

Le lundi 04 juillet 2011 à 23:00 +0200, Tosh Cooey a écrit :
> On 7/4/11 12:33 PM, Dave Hodgkinson wrote:

> >> Is there a reason for the lack of plug'n'play mod_perl LAMP cloud service providers? Or are there a ton that I just don't know about?
> >>
> >
> > Because you really should build your own perl, mod_perl and Apache stack.
> >
>
> I fail
> to see a benefit in building your own perl, mod_perl and Apache stack.
>

A plug'n'play Apache/mod_perl stack sounds to me like an oxymoron,
specially if you also use a database. If you need that power, you must
be able to tune it, maybe not for optimization but certainly for
security.

I haven't used it myself, but this was mentionned on the list a few days
back :

http://plackperl.org/

Maybe that's more adapted for your needs?

As far as building a stack goes, I agree with André's reply in the other
part of this thread :

"Ah, the beauty of being able to apt-get install libapache2-mod-perl2"

This is what I use:

apt-get install libapache2-request-perl libapreq2 libapache-dbi-perl libapache2-mod-perl2 apache2-mpm-prefork apache2-doc apache2-utils

#edit /etc/apache2/conf.d/security
ServerSignature Off
ServerTokens Minimal

I have to install a few Perl modules that I use, but all that's left to
do is create the virtual hosts files to be up and running.


--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique

Re: Re: mod_perl EC2 AMI"s or other platform providers?

Mr. Hodgkinson was awesome enough to point out the existence of
DotCloud: https://docs.dotcloud.com/#perl.html

Looks there like they have a Perl stack available, which is super for
the world but not so for me since the stack requires you use PSGI which
is a great approach but since I don't require portability I never went
that route, oh woe is me...

Anyway, it's good to see there's some good Perl options out there for
getting rid of my admin(s).

Thanks Dave!

Tosh



On 7/22/64 8:59 PM, Tosh Cooey wrote:
> The point was, and is, that it's unfortunate that mod_perl developers
> need to:
>
> 1) Build and optimize Apache.
> 2) Build and optimize MySql.
> 3) Build and optimize Perl+mod_perl.
> 4) Build and optimize a Linux server environment.
> or
> 5) Have enough money to pay for all of the above.
>
> Those are all roadblocks to development, much like your responses are to
> this discussion.
>
> My life would be a different experience if I could pay for six months of
> your time whenever I wanted to create a new web application.
>
> It would be nice to fire up a mod_perl stack somewhere (say EC2) and
> then just modify startup.pl and install your required modules and go.
>
> The dev world is moving away from requiring system administrators and
> towards more PaaS'.
>
> Tosh
>
>
>
> On 7/5/11 10:48 AM, Dave Hodgkinson wrote:
>>
>> On 5 Jul 2011, at 08:53, Tosh Cooey wrote:
>>
>>> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>>>
>>>>>
>>>>> I'm not happy, hence the complaining about the AMI from 2009. But
>>>>> I'm glad you changed the subject from your first one, which is that
>>>>> I should build my own stack.
>>>>>
>>>>> So basically you are saying (and only you, not a community voice)
>>>>> that in order to be a mod_perl developer one also needs to:
>>>>>
>>>>> 1) Build and optimize Apache.
>>>>> 2) Build and optimize MySql.
>>>>> 3) Build and optimize Perl+mod_perl.
>>>>> 4) Build and optimize a Linux server environment.
>>>>> or
>>>>> 5) Have enough money to pay for all of the above.
>>>>
>>>> You have no stack.
>>>>
>>>> Make one.
>>>>
>>>> Better still, get a bunch of people together with the same problem.
>>>> Dunno where
>>>> you'd find 'em.
>>>>
>>>> I just spent six months helping a company do exactly[0] this and
>>>> move off a dated
>>>> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN
>>>> modules.
>>>
>>>
>>> You seem to have missed the point of my kvetching, which is perhaps a
>>> suitable answer anyway.
>>
>>
>> What was the point?
>

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

Also, I believe DotCloud has Miyagawa on board which is a big win IMHO.
Legend has it he had perl support shipped two days after joining. Or
something.

I'm about to put a Catalyst app on it so we'll see how that flies.


On 10 Jul 2011, at 11:28, Tosh Cooey wrote:

> Mr. Hodgkinson was awesome enough to point out the existence of =
DotCloud: https://docs.dotcloud.com/#perl.html
>=20
> Looks there like they have a Perl stack available, which is super for =
the world but not so for me since the stack requires you use PSGI which =
is a great approach but since I don't require portability I never went =
that route, oh woe is me...
>=20
> Anyway, it's good to see there's some good Perl options out there for =
getting rid of my admin(s).
>=20
> Thanks Dave!
>=20
> Tosh
>=20
>=20
>=20
> On 7/22/64 8:59 PM, Tosh Cooey wrote:
>> The point was, and is, that it's unfortunate that mod_perl developers
>> need to:
>>=20
>> 1) Build and optimize Apache.
>> 2) Build and optimize MySql.
>> 3) Build and optimize Perl+mod_perl.
>> 4) Build and optimize a Linux server environment.
>> or
>> 5) Have enough money to pay for all of the above.
>>=20
>> Those are all roadblocks to development, much like your responses are =
to
>> this discussion.
>>=20
>> My life would be a different experience if I could pay for six months =
of
>> your time whenever I wanted to create a new web application.
>>=20
>> It would be nice to fire up a mod_perl stack somewhere (say EC2) and
>> then just modify startup.pl and install your required modules and go.
>>=20
>> The dev world is moving away from requiring system administrators and
>> towards more PaaS'.
>>=20
>> Tosh
>>=20
>>=20
>>=20
>> On 7/5/11 10:48 AM, Dave Hodgkinson wrote:
>>>=20
>>> On 5 Jul 2011, at 08:53, Tosh Cooey wrote:
>>>=20
>>>> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>>>>=20
>>>>>>=20
>>>>>> I'm not happy, hence the complaining about the AMI from 2009. But
>>>>>> I'm glad you changed the subject from your first one, which is =
that
>>>>>> I should build my own stack.
>>>>>>=20
>>>>>> So basically you are saying (and only you, not a community voice)
>>>>>> that in order to be a mod_perl developer one also needs to:
>>>>>>=20
>>>>>> 1) Build and optimize Apache.
>>>>>> 2) Build and optimize MySql.
>>>>>> 3) Build and optimize Perl+mod_perl.
>>>>>> 4) Build and optimize a Linux server environment.
>>>>>> or
>>>>>> 5) Have enough money to pay for all of the above.
>>>>>=20
>>>>> You have no stack.
>>>>>=20
>>>>> Make one.
>>>>>=20
>>>>> Better still, get a bunch of people together with the same =
problem.
>>>>> Dunno where
>>>>> you'd find 'em.
>>>>>=20
>>>>> I just spent six months helping a company do exactly[0] this and
>>>>> move off a dated
>>>>> RH platform onto a modern, current, Debian, perl 5.14, all new =
CPAN
>>>>> modules.
>>>>=20
>>>>=20
>>>> You seem to have missed the point of my kvetching, which is perhaps =
a
>>>> suitable answer anyway.
>>>=20
>>>=20
>>> What was the point?
>>=20
>=20
> --=20
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl EC2 AMI"s or other platform providers?

On 07/10/2011 06:28 AM, Tosh Cooey wrote:

> Looks there like they have a Perl stack available, which is super for
> the world but not so for me since the stack requires you use PSGI which
> is a great approach but since I don't require portability I never went
> that route, oh woe is me...

PSGI isn't just about portability, it's also about middleware. With a
common interface between components we get out of the rut where each new
cool plugin was re-implemented by every existing framework. Now most
things can just be written as PSGI middleware and anything can use it no
matter what your framework (or lack of one).

For instance, these are some handy ones to have:

Plack::Middleware::InteractiveDebugger
Plack::Middleware::REPL
Plack::Middleware::Firebug::Lite
Plack::Middleware::JSONP
Plack::Middleware::RefererCheck
Plack::Middleware::Static::Minifier
Plack::Middleware::HTMLMinify
Plack::Middleware::Mirror
Plack::Middleware::iPhone

And there's a ton more. Yes lots of them can be done with other existing
Apache modules (but not all of them) and lots of them might already
exist in your framework of choice. But pulling things out into
middleware seems to be the future of such work and will thus get new
features and be better maintained than lots of other alternatives.

--
Michael Peters
Plus Three, LP

Re: mod_perl EC2 AMI"s or other platform providers?

I saw Miyagawa at YAPC::NA and it looks like DotCloud is serious about
their Perl support.

The situation seems pretty good to me. We have DotCloud, for people
who want to try something simple very quickly with minimal startup
costs. We have cheap virtual servers (e.g. Linode) running linux with
simple installation of pre-compiled perl, apache, and mod_perl, for
those who want a little more control but can live with outdated
versions in exchange for ease of administration. Then we have
compile-your-own, for those running large systems who want the latest
versions and need the best performance and debugging possible. I
don't think we're missing anyone at this point.

- Perrin

On Sun, Jul 10, 2011 at 7:22 AM, Dave Hodgkinson wrote:
> Also, I believe DotCloud has Miyagawa on board which is a big win IMHO.
> Legend has it he had perl support shipped two days after joining. Or
> something.
>
> I'm about to put a Catalyst app on it so we'll see how that flies.
>
>
> On 10 Jul 2011, at 11:28, Tosh Cooey wrote:
>
>> Mr. Hodgkinson was awesome enough to point out the existence of DotCloud: https://docs.dotcloud.com/#perl.html
>>
>> Looks there like they have a Perl stack available, which is super for the world but not so for me since the stack requires you use PSGI which is a great approach but since I don't require portability I never went that route, oh woe is me...
>>
>> Anyway, it's good to see there's some good Perl options out there for getting rid of my admin(s).
>>
>> Thanks Dave!
>>
>> Tosh
>>
>>
>>
>> On 7/22/64 8:59 PM, Tosh Cooey wrote:
>>> The point was, and is, that it's unfortunate that mod_perl developers
>>> need to:
>>>
>>> 1) Build and optimize Apache.
>>> 2) Build and optimize MySql.
>>> 3) Build and optimize Perl+mod_perl.
>>> 4) Build and optimize a Linux server environment.
>>> or
>>> 5) Have enough money to pay for all of the above.
>>>
>>> Those are all roadblocks to development, much like your responses are to
>>> this discussion.
>>>
>>> My life would be a different experience if I could pay for six months of
>>> your time whenever I wanted to create a new web application.
>>>
>>> It would be nice to fire up a mod_perl stack somewhere (say EC2) and
>>> then just modify startup.pl and install your required modules and go.
>>>
>>> The dev world is moving away from requiring system administrators and
>>> towards more PaaS'.
>>>
>>> Tosh
>>>
>>>
>>>
>>> On 7/5/11 10:48 AM, Dave Hodgkinson wrote:
>>>>
>>>> On 5 Jul 2011, at 08:53, Tosh Cooey wrote:
>>>>
>>>>> On 7/4/11 11:26 PM, Dave Hodgkinson wrote:
>>>>>>
>>>>>>>
>>>>>>> I'm not happy, hence the complaining about the AMI from 2009. But
>>>>>>> I'm glad you changed the subject from your first one, which is that
>>>>>>> I should build my own stack.
>>>>>>>
>>>>>>> So basically you are saying (and only you, not a community voice)
>>>>>>> that in order to be a mod_perl developer one also needs to:
>>>>>>>
>>>>>>> 1) Build and optimize Apache.
>>>>>>> 2) Build and optimize MySql.
>>>>>>> 3) Build and optimize Perl+mod_perl.
>>>>>>> 4) Build and optimize a Linux server environment.
>>>>>>> or
>>>>>>> 5) Have enough money to pay for all of the above.
>>>>>>
>>>>>> You have no stack.
>>>>>>
>>>>>> Make one.
>>>>>>
>>>>>> Better still, get a bunch of people together with the same problem.
>>>>>> Dunno where
>>>>>> you'd find 'em.
>>>>>>
>>>>>> I just spent six months helping a company do exactly[0] this and
>>>>>> move off a dated
>>>>>> RH platform onto a modern, current, Debian, perl 5.14, all new CPAN
>>>>>> modules.
>>>>>
>>>>>
>>>>> You seem to have missed the point of my kvetching, which is perhaps a
>>>>> suitable answer anyway.
>>>>
>>>>
>>>> What was the point?
>>>
>>
>> --
>> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
>
>

Re: mod_perl EC2 AMI"s or other platform providers?

From: "Perrin Harkins"
>I saw Miyagawa at YAPC::NA and it looks like DotCloud is serious about
> their Perl support.
>=20
> The situation seems pretty good to me. We have DotCloud, for people
> who want to try something simple very quickly with minimal startup
> costs. =20

I have tried, or better said tried to try DotCloud. :-)
But I couldn't access it from Windows. They say that for the moment they =
don't really support Windows but I read a blog with some tips for making =
it work under Windows.

The problem was that rsync didn't work under Windows, or at least this =
is what their client program said.

I have installed cwRsync that includes cygwin and rsync, but I don't =
know for what reason... it didn't work.

For the moment their pricing plan is not clear for me.

0 USD/Mo is clear, and I understand that for this it offers 2 services, =
that can be say... Perl and MySQL.

The second level... is 99 USD/Mo for which they offer 4 services, but =
without beeing clear about the processors/memory/space (or I missed that =
part), and this second step is much expensive than the first few tariff =
plans of linode.

I was interested by DotCloud because I wanted to see how accessible is =
the interface they offer, but for the moment... it is not very.

If you know something more about these, please tell us.

Perl programs are usually harder to deploy than the PHP apps, and it =
would be very good if there would be a solution easy to use for apps =
wich are a little more complex.

Octavian