> > What technique to help the scanners were you thinking about?
>
> How about my X-Powered-By suggestion for a while ago ?
>
> http://perl.apache.org/advocacy/issues.html#X_Powered_By
>
i think that's a great idea.
-
To unsub
Stas Bekman wrote:
Frank Wiles wrote:
On Mon, 01 Nov 2004 17:47:26 -0500
Stas Bekman <[EMAIL PROTECTED]> wrote:
for some reason we still don't have the numbers for Oct 2004 from
netcraft but regardless it's easy to see that the stats are getting
worse all the time:
http://perl.apache.org/outstandin
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
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 wou
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 ligh
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
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
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
impleme
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 deliv
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
On Tue, 30 Nov 2004 22:38:11 +
[EMAIL PROTECTED] 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 a
On Tue, 2004-11-30 at 22:38 +, [EMAIL PROTECTED] 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, whi
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)
On Tue, 2004-11-30 at 16:05 -0500, Marc Slagle wrote:
> Including the information that $X million is run through the system in
> a day/month/year would be more for the benefit of those who are not
> going to be doing the programming. Sometimes it would help for a
> developer to go to their boss an
Perrin Harkins wrote:
On Tue, 2004-11-30 at 11:35 -0500, Marc Slagle wrote:
If there is a way to go back and get the numbers on the
total dollar value of the orders run through the EToys system, it would
probably be a good bit of information to include.
Why would this
On Tue, 30 Nov 2004 14:45:51 -0500
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> I think what you're looking for is what Craig McLane (of
> Ticketmaster.com) does in his talks at conferences, where he discusses
> how much they save by using open source. Check this one out:
> http://www.linuxjournal
On Tue, 2004-11-30 at 11:53 -0800, Randal L. Schwartz wrote:
> Oh, then this was slightly before you? There was a study comparing
> mod_perl to three other technologies for the "rewrite" of the site,
> and was the reason mod_perl was chosen as the "new technology", not
> just because you had legac
> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
Perrin> In the case of eToys, they used Perl because the two Cal Tech
Perrin> students they hired to build the site liked it. Later, they
Perrin> ported some of it to Apache::Registry in order to keep up with
Perrin> the load. When I j
On Tue, 2004-11-30 at 11:35 -0500, Marc Slagle wrote:
> If there is a way to go back and get the numbers on the
> total dollar value of the orders run through the EToys system, it would
> probably be a good bit of information to include.
Why would this be relevant? To show that people trusted r
On Tue, 2004-11-30 at 08:55 -0800, Randal L. Schwartz wrote:
> Perrin, you know the one I mean, the study of *why* you chose mod_perl
> there. With real hard objective numbers about performance and defect
> rates and time-to-deploy.
But... it wasn't like that. I doubt it ever really is. Technic
> "Marc" == Marc Slagle <[EMAIL PROTECTED]> writes:
Marc> If there is a way to go back and get the numbers on the total
Marc> dollar value of the orders run through the EToys system, it
Marc> would probably be a good bit of information to include. I only
Marc> mention the EToys article becau
On Tue, 30 Nov 2004 11:35:25 -0500
Marc Slagle <[EMAIL PROTECTED]> wrote:
> While the stories on the site are great, almost none of them make any
> mention of the financial success of the project. They are very useful
>
> in showing other developers what mod_perl has to offer, but are
> diffic
While the stories on the site are great, almost none of them make any
mention of the financial success of the project. They are very useful
in showing other developers what mod_perl has to offer, but are
difficult to use in convincing someone who only cares about "revenue
generation." If ther
23 matches
Mail list logo
