Geoffrey Young wrote:
I apologize in advance if because of my mass snipping I've taken you out of context.Perrin Harkins wrote:On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote:
well, I think it really depends on what you want to accomplish. all the above really seems like just a perl versus php (or $web_language) debate: both run on a number of different server platforms, have strong followings, and are proven scalable and "enterprise" (sorry for throwing out that term, but you get the idea :). in the end, arguments like the above are very, very important ones for us as perl programmers, but I don't think they help mod_perl prosper as a technology, which is what I'm interested in :)while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API, and I would prefer to use it in conjunction with Perl rather than mess around with C (or even something like apache_hooks, since I don't know php :) for those that share a love for this particular aspect of mod_perl and have a desire to see it prosper, nothing else will really do. if mod_perl is just a means to performance ends similar to the other technologies you mention, it would be simpler and more efficient to strip mod_perl down to just an embedded interpreter and support development of just Registry.pm and the minimal API it requires. I think mod_perl more than that, and that is why I feel beaten down when nobody seems to care about mod_perl for what it really is, or people say you can just swap it out for FastCGI or something and things move on. that's when I feel like I'm wasting my time.
While I think you are right that mod_perl is more than that, I do wonder what people really care about. I have to say that although I love the speed of mod_perl, I find that for most tasks I have to do, I do not require even a persistant perl interpreter. I just like using Perl.
I've only used the Apache API a few times and that was when I was trying to emulate Sybase's WebSQL and hoping to convert all our Sybase WebSQL apps to mod_perl at a past organization I was at. If it weren't for the peculiar ways in which WebSQL did it's stuff, I probably would have just as soon run with Apache::Registry. So I suppose I would be in that camp that frustrates you. :)
I like using Perl or mod_perl for web apps because I know that Perl can be used as a cron job, as a scripting language, as a glue, for sysadmin tools already written in Perl (eg log_accum.pl) etc. I feel as if I learn PHP then I would have to still learn Perl for the non-web stuff. So why not kill two birds with one stone?
One thing I found interesting was Perrin bringing up the idea of different ways of using Perl. I still think that there is a key here. However, it's again I wonder about what is really mod_perl specific PR and what is perl specific PR.
Unless I am mistaken, I think Bioinformatics was brought up in this mailing list as one possible class of apps to talk about here. Here actually, I am not sure mod_perl really shines relative to Perl. Bioinformatics apps tend to call algorithms or statistics that may run for such a long time that adding the small amount of time it takes for Perl interpreter to load on a reasonably recent Linux box is really not noticeable. It's nice to use mod_perl, but not something that makes people scream if mod_perl isn't on a typical bioinformatics web server which usually emphazises small number of PhDs running complex algorithms.
It has always seemed to me that mod_perl shines more for apps that are retail or heavy in usage where you need to accommodate many hits and each hit does something very small that would be terrible for a slow-down to occur (like amazon front page or a porn site). I am not sure if this is another "issue" about PR for mod_perl -- why use it if machines are fast enough to support plain CGI/Perl these days? Perl saved the Human Genome Project. mod_perl didn't, although maybe mod_perl saved more than one slow webstore?
With that said about bioinformatics in particular, I think I would carry the idea of classes of apps one step further. I think the key to mod_perl being noticed is really about the apps not about touting the technology. It's one level of PR to claim that a website that is popular like Whatever.com is using mod_perl, but quite another for whatever.com to share their code so that others who want to do the same thing download the code and use mod_perl because the app said "use mod_perl".
To me, it seems PHP has a lot more apps touting the use of PHP (even if indirectly) than mod_perl apps do. There are a lot of free Perl apps out there, but mod_perl apps.... on perl.apache.org tI count about 15 apps total (not counting "toolkits" or core "tools" like CMS systems). This is part of a chicken and egg problem. On the one hand, if you have a lot of apps, you are more likely to see adoption of the technology and if the technology is well adopted, you are likely to see a lot more apps.
Along with the apps is the convincing of the ISPs to support mod_perl. How many support PHP (A lot I would gather?) and how many support mod_perl? I gather it's about 50 from the directory of ISPs on the mod_perl site, but how actively do they really support mod_perl? Do they support it? Or does it come by default along with PHP with every single shared user www account someone gets for the going rate of 9.99$/month?
Another issue...
has anyone gone to the following URLs:
www.modperl.com -- a website for the "first" book but the link to the real modperl site is actually buried way down as one of the links
www.modperl.org (some consulting firm called powerdata?)
www.mod_perl.com (doesn't exist)
www.mod_perl.org (doesn't exist)
For PR, I would think it would be nice for common URLs such as these to be freed up and appropriately used or redirected to perl.apache.org
As an only semi-frequent user of perl.apache.org, I really prefer typing www.modperl.com or .org and not having to remember the *.apache.org convention. Call me crazy, but even though I use pubmed several times a week, I still find myself just typing www.pubmed.com instead of the real url: http://www.ncbi.nlm.nih.gov/entrez/query.fcgi. Similar concept.
Gosh, I guess I am being very negative in this email. Sorry if I come across that way.
I could be wrong, but I suppose a positive way moving forward would be to resolve the following issues to generate more positive PR for mod_perl in the following summary:
1) Promoting classes of applications that use mod_perl
eg Success stories for classes of applications that use mod_perl (maybe even bioinformatics)
a once a month "interview" with someone using mod_perl successfully would make a nice repetoire of more stories.
2) Promoting applications that use mod_perl
If you've written a useful app that uses mod_perl at your workplace, please see if your employer would consider allowing it to be open sourced.
3) Let's get the domain names in order.
eg It's nice that Lincoln and Doug have had modperl.com all these ages, but now that their book has been out for years, it would be nice to give the URL back to the community and instead have their book use a more appropriate URL like modperlbook.com. Likewise for other URLs.
4) ISPs That support mod_perl
This is a tough one but I think it would be interesting to know what supporting mod_perl means for the 50 ISPs on the list. Is there a way that they can share their secrets (ala #1) to encouraging other ISPs to support mod_perl. Can people evangelize the use of mod_perl on their servers? I suppose this may only happen if there are enough apps in #2 to force the ISPs to want to enable mod_perl by default though...
5) Create a google bomb whereby when "web apps of mass domination" is searched, perl.apache.org comes up. Then report the google bomb as a news item on slashdot.
I guess I should stop my spewing now. I wish everyone here luck in promoting mod_perl.
Thanks,
Gunther
