Mailing List Archive

On Tue, 2004-11-30 at 22:38 +0000, modperl@att.net wrote:
> 4) avoid toolkits but diretly go to XHTML.

What are these toolkits you're talking about? Things like Mason,
Apache::ASP, and Template Toolkit? I wouldn't want to tell people not
to use templates. These things provide ease of use, which really
matters to some.

- Perrin


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

On Tue, 30 Nov 2004 22:38:11 +0000
modperl@att.net wrote:

> First, sorry to Frank. I was replying his email in the user list
> but was wrongly put his address as the subject. :-(

No worries.

> 1) easy to program
>
> cgi is very easy to use, and php is easy. mod_perl and
> java servlet are hard.

A Perl CGI can easily be "mod_perl enhanced" by a few simple
Apache configuration changes. I don't see what is so hard about
that. I also think mod_perl is much easier for a Perl programmer
to migrate toward than a Perl programmer taking up PHP or Java.
The learning curve is bitten off in more easily digestable chunks.

> 3) capacity/scalable
>
> mod_perl is very scalable --- I mean, one can properly
> config a single server to handle dynamic content for
> 200K daily unique IPs. PHP may end up with just 100K
> and servlet ends up at around 50K.
>
> However, even the old CGI can handle 20K unique IPs
> with a new CPU. Since most sites won't
> need to go above 20K IPs, this advantage is not that
> attractive in practice.
>
> And what is worse is that the current existing mod_perl
> toolkits seem not scalable when compared to PHP. I knew
> 2 cases where people gave up the mod_perl toolkit
> and turned to PHP.

I'm not sure which toolkit they gave up on, but I've found that
a lot of people give up too easily on these things. Often their
problem can be solved by a few quick config changes and tweaks if
they would just google for it or ask on a mailing list.

Also, like you said most sites will never run into these problems
and some of us aren't running traditional websites with mod_perl, but
using it for web applications that aren't hit at the same rates as
websites.

> 4) easy to manage, work as team
>
> both mod_perl and servlet are good to be written in OO
> (and the so-called MVC). PHP is bad.
>
> But again, majority webmasters don't need OO or MVC.

I think this is more of a function of how the programmers work than
the language or programming methodology. History has shown you can
build large projects with hundreds of developers in a non-OO style
and with no revision control ( read linux kernel until a few years
ago ).

> 5) learning curve, friendly environment, existing applications etc.
>
> PHP is the best, then serverlet; mod_perl is the worst.

Learning curve really depends on where you are coming from. If you're
talking about a webmaster that only knows Dreamweaver, XHTML, and a
smattering of CSS, learning Java servelets and mod_perl are probably
on equal footing.

However, if you already know a smattering of Perl, which most
webmasters or admins already do, then learning mod_perl is just
another small step. You already know the language, you just have to
learn the Apache API.

> Based on the above situation, we see that the potential mod_perl
> users are those who are using or will choose Java servlet,
> and advanced PHP users who need the projects to be in OO and MVC.
>
> To advocate mod_perl, the priorities rank as:
> 1) focus on mod_perl's ability of OO / MVC
> 2) scalability (only the original mod_perl, not toolkits)
> 3) and speed
> 4) avoid toolkits but diretly go to XHTML.

I disagree with this a bit as the toolkits can scale, they just
sometimes need to be tuned for a site. For example, I know there are
large sites out that using Template Toolkit and Mason without any
trouble. I'm sure they have had to tweak their configs, but if you're
running a large scale website without doing some tweaking you are
spending WAY too much money on hardware! :)

---------------------------------
Frank Wiles <frank@wiles.org>
http://www.wiles.org
---------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

<don flamesuit>

One thing people don't talk about much is deployability.
I've had to start moving away from ModPerl in some
situations for just this reason.

For example, my recent projects revolve around a public
server that everyone can use with the option to install a
local server on their network that delivers the same
functionality (same codebase with some some tweaks based on
its configuration status). The install has to go smoothly
every single time on a variety of platforms.

Originally I tried to get modperl up in this environment and
it really just was tough., module dependancies, things like
that. Additionally, and I know this is not cool to say, I
didn't really want the entire codebase sitting on someone's
machine since its a shrinkwrap product in a highly
competitive space. Yea yea, you can reverse compile java
classes etc etc etc, its just not the same as 'open the .pm
file'.

So that lead to java (Tomcat+Struts) which pretty quickly
and easily gave me a single package deployment method, no
source included and with no dependancies to speak of. Its
literally a double-click installer and a reboot(just to be
cautious, not really required) and the entire system is up
and running with a reverse proxy, tomcat, struts and all our
apps.

I know I could have accomplished this with modperl but
having done many modperl install packages in the past I know
its just not as easy and not nearly as bulletproof.

I still use a lot of modperl (South African Airways Holidays
etc) but whenever deployability is a key feature I've moved
to Java. Its not so bad once you get used to doing things in
longhand ;)

Solve the deployability issue and I'd jump back in a
heartbeat on those projects. A better way to package
dependancies up, obsfuscated source etc.
</remove flamesuit>

John, still loving my modperl but I've gone to the dark side
on more regular basis over the last year.

----- Original Message Follows -----
From: modperl@att.net
To: advocacy@perl.apache.org
Subject: Why people not using mod_perl
Date: Tue, 30 Nov 2004 22:38:11 +0000

> Hi, there:
>
> just subscribed to this advocacy list.
>
> First, sorry to Frank. I was replying his email in the
> user list but was wrongly put his address as the subject.
> :-(
>
> Please let me share some of my experiences in using
> mod_perl.
>
> There are four factors when choose a particular language:
>
> 1) easy to program
>
> cgi is very easy to use, and php is easy. mod_perl and
> java servlet are hard.
>
> 2) speed
>
> mod_perl is fast but php is fast too (if not faster),
> and so is Java servlet.
>
> 3) capacity/scalable
>
> mod_perl is very scalable --- I mean, one can properly
> config a single server to handle dynamic content for
> 200K daily unique IPs. PHP may end up with just 100K
> and servlet ends up at around 50K.
>
> However, even the old CGI can handle 20K unique IPs
> with a new CPU. Since most sites won't
> need to go above 20K IPs, this advantage is not that
> attractive in practice.
>
> And what is worse is that the current existing mod_perl
> toolkits seem not scalable when compared to PHP. I knew
> 2 cases where people gave up the mod_perl toolkit
> and turned to PHP.
>
> 4) easy to manage, work as team
>
> both mod_perl and servlet are good to be written in OO
> (and the so-called MVC). PHP is bad.
>
> But again, majority webmasters don't need OO or MVC.
>
> 5) learning curve, friendly environment, existing
> applications etc.
>
> PHP is the best, then serverlet; mod_perl is the worst.
>
>
> Based on the above situation, we see that the potential
> mod_perl users are those who are using or will choose
> Java servlet, and advanced PHP users who need the
> projects to be in OO and MVC.
>
> To advocate mod_perl, the priorities rank as:
> 1) focus on mod_perl's ability of OO / MVC
> 2) scalability (only the original mod_perl, not toolkits)
> 3) and speed
> 4) avoid toolkits but diretly go to XHTML.
>
>
> POD MERL
>
> ----------------------------------------------------------
> ----------- To unsubscribe, e-mail:
> advocacy-unsubscribe@perl.apache.org For additional
> commands, e-mail: advocacy-help@perl.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

At 02:38 PM 11/30/2004, you wrote:
>Hi, there:
>
>just subscribed to this advocacy list.
>
>First, sorry to Frank. I was replying his email in the user list
>but was wrongly put his address as the subject. :-(
>
>Please let me share some of my experiences in using mod_perl.
>
>There are four factors when choose a particular language:
>
>1) easy to program
>
>cgi is very easy to use, and php is easy. mod_perl and
>java servlet are hard.


For most people I have worked with/for, this is number one. The rest can
take a hike. Anything else is often considered a bias or religion. THAT is
why PHP is so big, quick and dirty rules. And remember, it is about this
perception, not the reality and it is not considering the consequences.
PHP is loaded with special functions for things that are just not that fing
hard to do, but they make things easier, at least that is the opinion. I
myself HATE big APIs that is why I have avoided Java to a large degree, and
PHP is just insane, esp with not even being able to have consistent names
for the functions that keep getting piled on. It is also getting a lot
easier to do MVC with PHP. For example a guy ported CGI::Application to PHP
and that combined with Smarty template is pretty close to what you would be
doing with Perl and does avoid at least a lot of the mess I see with a lot
of PHP collections.


>2) speed
>
>mod_perl is fast but php is fast too (if not faster),
>and so is Java servlet.


I did some benchmarks on our servers, without tweaking/Zend PHP can dog it
just as bad as CGI, assuming it is not running as a CGI which is still not
at all uncommon. It actually surprised me. But like you were saying what it
does is enough for what we need on those servers. I was comparing a nothing
PHP script to a mod_perl Registry big ass app too. Yes, just our one case..


>3) capacity/scalable
>
>mod_perl is very scalable --- I mean, one can properly
>config a single server to handle dynamic content for
>200K daily unique IPs. PHP may end up with just 100K
>and servlet ends up at around 50K.
>
>However, even the old CGI can handle 20K unique IPs
>with a new CPU. Since most sites won't
>need to go above 20K IPs, this advantage is not that
>attractive in practice.
>
>And what is worse is that the current existing mod_perl
>toolkits seem not scalable when compared to PHP. I knew
>2 cases where people gave up the mod_perl toolkit
>and turned to PHP.
>
>4) easy to manage, work as team
>
>both mod_perl and servlet are good to be written in OO
>(and the so-called MVC). PHP is bad.
>
>But again, majority webmasters don't need OO or MVC.
>
>5) learning curve, friendly environment, existing applications etc.
>
>PHP is the best, then serverlet; mod_perl is the worst.


This part I don't get. When I ask a semi advanced question on a PHP list I
get a lot of just stupid responses or dead air. Biggest in this case is
certainly not best. On the mod_perl list I pretty much end up feeling
stupid for asking the question, because the answer comes so quickly and is
so simple :)



>Based on the above situation, we see that the potential mod_perl
>users are those who are using or will choose Java servlet,
>and advanced PHP users who need the projects to be in OO and MVC.
>
>To advocate mod_perl, the priorities rank as:
>1) focus on mod_perl's ability of OO / MVC
>2) scalability (only the original mod_perl, not toolkits)
>3) and speed
>4) avoid toolkits but diretly go to XHTML.
>
>
>POD MERL
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
>For additional commands, e-mail: advocacy-help@perl.apache.org


Lead Programmer
D.M. Contact Management
250.383.8267 ext 229


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

I second this one. I always find my self fine tuning peoples
PHP code before I'll deploy it. Its not that PHP is a bad
language but a lot of the people doing it really don't grasp
the finer aspects of writing code in a scalable fashion and
are new to the scene. They end up doing things like
implementing unpredictable levels of SQL queries etc, it can
just kill performance.

There was one guy who would generate a random number, query
an sql table to see if it existed and did it in a loop until
he hit on a number that existed. He never quite grasped why
it was such a randomly bad performing system :)

But everyone learns, I cringe when I look back to my first
perl code.

John-

---Eric said----
This part I don't get. When I ask a semi advanced question
on a PHP list I
get a lot of just stupid responses or dead air. Biggest in
this case is
certainly not best. On the mod_perl list I pretty much end
up feeling
stupid for asking the question, because the answer comes so
quickly and is
so simple :)

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

1) with toolkits, we may pay the price of losing core mod_perl
features. The users will then get a tool that is not
apprently richer than PHP in functions.

2) TT or HTML::Templates are good in seperating HTML
from program. But for Mason and ASP, we still need to put
program with the HTML in one file.

As a conclusion, while toolkits are good and make
mod_perl easier to program, they also make mod_perl more
similar to PHP and so be less attrative.


> 4) avoid toolkits but diretly go to XHTML.

What are these toolkits you're talking about? Things like Mason,
Apache::ASP, and Template Toolkit? I wouldn't want to tell people not
to use templates. These things provide ease of use, which really
matters to some.

- Perrin

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

----------------------------------------------------------------------------
Eric wrote:

... It is also getting a lot
easier to do MVC with PHP. For example a guy ported CGI::Application to PHP
and that combined with Smarty template is pretty close to what you would be
doing with Perl and does avoid at least a lot of the mess I see with a lot
of PHP collections.
---------------------------------------------------------------------------

This is very interesting! A question:
Can PHP also be programed in inheritance classes? For example, one can
seperate a C cgi into different pieces as MVC, but without inheritance
or the ability of re-use of the classes, the seperation is less useful,
although it still helps a lot in the development.

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

In many casee, the hard part to deploy mod_perl application
seem due to the huge memory usage. But this can be solved
by using the dual (light+modperl) setup. The dual setup
has also another advantage: it allows virtual
hosting users to run his own standalone Apache at a given
port (have the light server to proxy to that port.)
The virtual host user still needs to restart his
mod_perl if program changes, but the light server does not,
and so the other users won't be affected.

The example you mentioned about using Java over Perl
looks interesting. Can you be more specific, since
we rarely hear cases where Perl can't do but Java. :-)


siberian wrote:

Tue, 30 Nov 2004 15:00:45 -0800

<don flamesuit>

One thing people don't talk about much is deployability.
I've had to start moving away from ModPerl in some
situations for just this reason.

For example, my recent projects revolve around a public
server that everyone can use with the option to install a
local server on their network that delivers the same
functionality (same codebase with some some tweaks based on
its configuration status). The install has to go smoothly
every single time on a variety of platforms.

Originally I tried to get modperl up in this environment and
it really just was tough., module dependancies, things like
that. Additionally, and I know this is not cool to say, I
didn't really want the entire codebase sitting on someone's
machine since its a shrinkwrap product in a highly
competitive space. Yea yea, you can reverse compile java
classes etc etc etc, its just not the same as 'open the .pm
file'.

So that lead to java (Tomcat+Struts) which pretty quickly
and easily gave me a single package deployment method, no
source included and with no dependancies to speak of. Its
literally a double-click installer and a reboot(just to be
cautious, not really required) and the entire system is up
and running with a reverse proxy, tomcat, struts and all our
apps.

I know I could have accomplished this with modperl but
having done many modperl install packages in the past I know
its just not as easy and not nearly as bulletproof.

I still use a lot of modperl (South African Airways Holidays
etc) but whenever deployability is a key feature I've moved
to Java. Its not so bad once you get used to doing things in
longhand ;)

Solve the deployability issue and I'd jump back in a
heartbeat on those projects. A better way to package
dependancies up, obsfuscated source etc.
</remove flamesuit>

John, still loving my modperl but I've gone to the dark side
on more regular basis over the last year.

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

At 03:34 PM 11/30/2004, you wrote:
>----------------------------------------------------------------------------
>Eric wrote:
>
>... It is also getting a lot
>easier to do MVC with PHP. For example a guy ported CGI::Application to PHP
>and that combined with Smarty template is pretty close to what you would be
>doing with Perl and does avoid at least a lot of the mess I see with a lot
>of PHP collections.
>---------------------------------------------------------------------------
>
>This is very interesting! A question:
>Can PHP also be programed in inheritance classes? For example, one can
>seperate a C cgi into different pieces as MVC, but without inheritance
>or the ability of re-use of the classes, the seperation is less useful,
>although it still helps a lot in the development.


That I am not as sure about, but I seem to remember hearing that PHP 5 at
least does now have real scoping. Sounds like a search engine question to
me. Before 5 lack of that made its objects a sad joke. But that is part of
the problem, every single damn thing that is added to PHP is added to PHP.
It just keep growing and growing. Even now XML-RPC is a part of the default
install, WHY??? And so many things have to be complied in in order for them
to work, if they are not included to start off with. That was another thing
that made me think there is no way I can do PHP and just pretend it is Perl
somehow.


>---------------------------------------------------------------------
>To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
>For additional commands, e-mail: advocacy-help@perl.apache.org


Lead Programmer
D.M. Contact Management
250.383.8267 ext 229


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

Yes, reverse proxies are king :) On my hosting servers I
have a light proxy fronting 3 modperl servers on a single
box (with a total of about 100 vhosts) and one tomcat
server(on the same box, haha). Its a pretty nice
configuration that really has done us well over the last 5+
years.

As far as my java app, its not that modperl could -not- do
it, but when we are selling hundreds of shrinkwrapped units
a month modperl becomes quickly unsupportable for me, there
are just too many variables once it gets into the field.
Where does that module go, whats that path to it, is there a
version conflict, what stupid thing did microsoft do now(we
deploy on windows) etc etc etc.

With the Java I can install tomcat, drop in a new server.xml
and plop in a .war file. HUP the server and I have a locally
installed system that only phones home for registration and
serialization purposes. If it doesnt find the signature in
the conf file it knows its a local machine, not a public
server, so its feature set reduces. That gives me a 100%
identical codebase in a single account/single box local
server and the public server that consists of four machines
and hundreds or thousands of accounts.

That ability to say 'this is my app, make it run now' is the
real attraction. Not being able to grok the source is a
requirement as well. Additionally, I can go multi-platform
with just a new install tool since everything works out of
the box without compiling. It really is incredibly seamless
and after more years modperling then I can count I've never
been able to get it that clean in deployment.

Like I said, nothing you can't DO with modperl but its just
a lot HARDER to do it and there are enough dragons to slay,
no need to add more to the mix.

John-


----- Original Message Follows -----
From: modperl@att.net
To: advocacy@perl.apache.org
Subject: Re: Why people not using mod_perl
Date: Tue, 30 Nov 2004 23:50:55 +0000

> In many casee, the hard part to deploy mod_perl
> application seem due to the huge memory usage. But this
> can be solved by using the dual (light+modperl) setup. The
> dual setup has also another advantage: it allows virtual
> hosting users to run his own standalone Apache at a given
> port (have the light server to proxy to that port.)
> The virtual host user still needs to restart his
> mod_perl if program changes, but the light server does not
> , and so the other users won't be affected.
>
> The example you mentioned about using Java over Perl
> looks interesting. Can you be more specific, since
> we rarely hear cases where Perl can't do but Java. :-)
>
>
> siberian wrote:
>
> Tue, 30 Nov 2004 15:00:45 -0800
>
> <don flamesuit>
>
> One thing people don't talk about much is deployability.
> I've had to start moving away from ModPerl in some
> situations for just this reason.
>
> For example, my recent projects revolve around a public
> server that everyone can use with the option to install a
> local server on their network that delivers the same
> functionality (same codebase with some some tweaks based
> on its configuration status). The install has to go
> smoothly every single time on a variety of platforms.
>
> Originally I tried to get modperl up in this environment
> and it really just was tough., module dependancies, things
> like that. Additionally, and I know this is not cool to
> say, I didn't really want the entire codebase sitting on
> someone's machine since its a shrinkwrap product in a
> highly competitive space. Yea yea, you can reverse compile
> java classes etc etc etc, its just not the same as 'open
> the .pm file'.
>
> So that lead to java (Tomcat+Struts) which pretty quickly
> and easily gave me a single package deployment method, no
> source included and with no dependancies to speak of. Its
> literally a double-click installer and a reboot(just to be
> cautious, not really required) and the entire system is up
> and running with a reverse proxy, tomcat, struts and all
> our apps.
>
> I know I could have accomplished this with modperl but
> having done many modperl install packages in the past I
> know its just not as easy and not nearly as bulletproof.
>
> I still use a lot of modperl (South African Airways
> Holidays etc) but whenever deployability is a key feature
> I've moved to Java. Its not so bad once you get used to
> doing things in longhand ;)
>
> Solve the deployability issue and I'd jump back in a
> heartbeat on those projects. A better way to package
> dependancies up, obsfuscated source etc.
> </remove flamesuit>
>
> John, still loving my modperl but I've gone to the dark
> side on more regular basis over the last year.
>
> ----------------------------------------------------------
> ----------- To unsubscribe, e-mail:
> advocacy-unsubscribe@perl.apache.org For additional
> commands, e-mail: advocacy-help@perl.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

On Tue, 30 Nov 2004 16:24:41 -0800
"siberian" <siberian@siberian.org> wrote:

> With the Java I can install tomcat, drop in a new server.xml
> and plop in a .war file. HUP the server and I have a locally
> installed system that only phones home for registration and
> serialization purposes. If it doesnt find the signature in
> the conf file it knows its a local machine, not a public
> server, so its feature set reduces. That gives me a 100%
> identical codebase in a single account/single box local
> server and the public server that consists of four machines
> and hundreds or thousands of accounts.

While this won't entirely solve your source readbility issue, you
might look into PAR to allow you to what you are accomplishing with
Java. At least with this it's a bit harder than just opening the
libraries.

---------------------------------
Frank Wiles <frank@wiles.org>
http://www.wiles.org
---------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org