At 18:04 03/12/1999 -0600, Jason Bodnar wrote:
>You really can't compare mod_perl to ASP or JSP, though, IMHO. Compare those
>two technologies to Embperl or ePerl or Apache::ASP.
That's true. And then compare mod_perl handlers with ISAPI extensions and
filters. Mod_perl isn't that hard after all :)
Perhaps if we want to seduce more people to mod_perl, it would be a good
idea to stress further the fact that there is no need to learn the Apache
API to get a hell of a lot of power from mod_perl. Knowing one of the Perl
embedding solutions is way enough to create a totally dynamic website that
goes much faster than CGI.
And here the thing to do would be to help people choose the mod_perl
solution they need. To speed up CGI, Registry is enough. To play with the
internals of the request process, you need the API. That's clear, yet it
could be made even clearer. The biggest problem arises when you want
ASP/JSP/CFML/etc style functionality. There are so many that it really gets
confusing. I've been at mod_perl for quite some time, but I must admit that
I've got no idea which of those would be best suited for which kind of job.
I haven't seen them all, but none of those I've seen were bad. Some have
more functionality than others, but smaller = less memory usage. It would
be really great if we could come up with a clear and short list of pros and
cons plus a brief description for each of them, and it would be even better
if that list came from the authors. The site organisation which I'll be
submitting tonight has a space for this. Any ideas ?
>The problem with an ISP supporting mod_perl is the fact that you're giving so
>much power to your clients. It's very easy to bring down an entire physical
>server by writing a bad handler (or even a bad embperl page).
True too, but then very few ISPs support ISAPI extensions, knowing that
these too break a server down when they fail. However one could imagine an
ISP supporting a Perl embedding scheme (provided that it is safe enough).
The problem is again which one to choose ?
>> MiniGuide == ManyPagesGuide now. The fact is that the knowledge is there.
>> But it really does require a guide that is that large to really know how
>> to do good mod_perl code and exploit its advantages. And even then...
Maybe a Guide to the Guide somewhere in between the refcard and the actual
Guide would be of some help.
At the same time, I think that a mod_perl cookbook would be a great idea.
If no one has the tuits to start that now, when the site is finished I
will. A few generic and well-documented handler examples for each type of
Perl*Handler would be good enough to start with, and then anyone can add.
However starting now would be great.
.Robin
James Joyce -- an essentially private man who wished his total indifference
to public notice to be universally recognized. -- Tom Stoppard
