Re: mod_perl marketing

[prev] [thread] [next] [Date index for 2004/11/30]

We have been using mod_perl successfully for several months now as a
flexible email proxy -- we just wrapped Net::Server::Mail and with a
few additional hacks and it worked. Matt Sergeant did the same thing
with qpsmtpd and I have heard that the performance results were
initially very promising
(http://msgs.securepoint.com/cgi-bin/get/qmail0411/120/1/1/1.html).

More details of our hack (patches etc.) are at
http://www.mailchannels.com/opensource and
http://search.cpan.org/~mock/Apache-SMTP-0.01/lib/Apache/SMTP.pm.

IMHO, using mod_perl as a general application server is a great
idea. For us there really was no other viable alternative. We looked
at POE, Sendmail's milter API, Net::Server and of course qpsmtpd but
the reliability, portability, and scalability of Apache was what
caused us to go through the effort of making our bits work on
mod_perl.

To configure a mail server, it's just a matter of adding a VirtualHost
section to the Apache configuration et voila. And as packages such as
mod_throttle move over to Apache 2, we will gain the wonderment of a
solid resource management tool for mail traffic. Joy!

TTUL
Ken

Frank Wiles [30/11/04 13:30 -0600]:
> On Tue, 30 Nov 2004 19:23:38 +0000
> modperl@xxx.xxx wrote:
> 
> > Please let me raise a question.
> > 
> > In practice, people who can program in other phases usually can
> > 1) program directly in C module; and 2) find that C provides
> > much better a solution.
> > 
> > For example, the authz phase in the dual-Apache setup.
> > Here the static files are served by the light Apache. A C 
> > autenz handler is usually more efficient and may be a must.
> > 
> > The same is true for the URL re-writing phase. Most likely we 
> > need the URL to be re-written for both dynamic contents and 
> > static files.
> > 
> > So, while mod_perl is able to handle other phases, in practice,
> > one may still need to go back to the C API for the best results.
> > 
> > In the content phase, I think the OO programming, and so
> > the MVC (Model-View-Control) concept,  makes mod_perl
> > much better a choice than PHP for large projects.
> 
>   I think you will find that mod_perl code is roughly the same
>   speed as a comporable C Apache module.  Since mod_perl holds all of
>   the code in memory we don't have a fork/compile/excute problem which
>   is why most people think C is way faster than Perl.  
> 
>   I've seen non response phase handlers, written in mod_perl, handle
>   better than commercial C modules.  I'm curious why you think a C
>   module would be a better solution? 
> 
>  ---------------------------------
>    Frank Wiles <frank@xxxxx.xxx>
>    http://www.wiles.org
>  ---------------------------------
> 
> 
> -- 
> Report problems: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> List etiquette: http://perl.apache.org/maillist/email-etiquette.html
> 
> 
> Sent by MailChannels: http://www.mailchannels.com

        -- 
        MailChannels: Assured Messaging

--
Eliminate Critical False Positives
http://www.mailchannels.com
MailChannels Corporation
Suite 1600, 1188 West Georgia St.
Vancouver, BC, Canada

Ken Simpson, CEO
+1-604-729-1741

Sent by MailChannels: http://www.mailchannels.com

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html