Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 57191 invoked from network); 8 Jun 2004 22:49:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Jun 2004 22:49:19 -0000 Received: (qmail 21051 invoked by uid 500); 8 Jun 2004 22:49:23 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 20942 invoked by uid 500); 8 Jun 2004 22:49:22 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 20824 invoked by uid 99); 8 Jun 2004 22:49:21 -0000 From: modperl@att.net To: modperl@perl.apache.org Subject: Re: Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger Date: Tue, 08 Jun 2004 22:48:54 +0000 Message-Id: <060820042248.13154.40C642560004E3FC000033622160280741049D0A9F0B0103@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: bW9kcGVybEBhdHQubmV0 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N It depends how to define "programming language". It seems more properly a comparison between php and Mason because mod_perl itself is the Apache API in Perl language. For newbies, this API is indeed hard to program with. My 2 cents is that mod_perl lacks an "established" application server/tookits so for a serious web application, programmers have to rely mostly on the original API to get the full benifit. While there sevearl great application tools like mason, ePerl, TT etc., yet, none of them is as "established" as php at the moment (in the sense: easy to write, support, coder community, code samples etc.) Occasionally, I thought we might start up with a new application server that has features like these: 1) MVC model; 2) XHTML templates; 3) backend programming based on XML (e.g. parsing parameters like STRUTS), so other java, .NET applications can be translated as easy as possible; 4) some special cares on the places where mod_perl may be weak (such as memory usuage), so there might be a few special C modules for things like system-wide authentication. and so on. Well, my random thoughts.... Pod Merl > Date: Tue, 8 Jun 2004 16:53:48 -0500 > From: Frank Wiles > To: Perrin Harkins > Subject: Re: mod_perl presence at OSCON (and other CONs) is at danger > ..... > > > In my opinion mod_perl definitly needs a lot of extra PR. > > > > My intention was that mod_perl would be talked about in the larger > > context of Perl, as the standard way to build web apps. There could > > be an ad promoting web development with mod_perl, one promoting > > Bioinformatics use, one promoting use in financial companies, one for > > sysadmin and DBA use, etc. > > > > If you notice, no one talks about mod_php. Instead they talk about > > PHP. That's because mod_php is just some glue code that lets you run > > PHP in apache, just like mod_perl lets you run Perl. I already run > > into people who know Perl and think that mod_perl is some other > > language they would have to learn, and that's not good. > > I agree that we should work to make sure mod_perl is accurately > portrayed and do our best to avoid misinterpretations that mod_perl > is a separate language, etc. > > --------------------------------- > Frank Wiles > http://frank.wiles.org > --------------------------------- > > > > > --------------------------------- > Frank Wiles > http://frank.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 > -- 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