[kw-pm] The mod_perl Talk
Arguile
arguile at lucentstudios.com
Mon Jun 9 02:50:29 CDT 2003
I was writing some more of the presentation tonight and upon review,
realised I might not be hitting the points people want. So I'd like to
take a little informal survey of what areas people are interested in. As
it currently stands the talk breaks down into these sections:
Installing mod_perl
Of the many, many methods possible I cover only the three easiest
/ most popular for brevity's sake. Binary install (both win32 and
*nix), simple build of Apache + static mod_perl (without any other
modules), and using APXS to add mod_perl as a DSO to existing apache
installs (without having to recompile apache).
Basic CGI under Apache::Registry and Apache::PerlRun
The first of two sections on this. This one covers simply how to
get it up and running without any in-depth explanation of why things
work the way they do.
What is mod_perl?
A brief history of the evolution of HTTP servers from compiling in
changes, to CGI, and then custom APIs. We then discuss persistant
Perl interpretters, both the good and bad features. And basically
describe what mod_perl does in high level terms.
Apache::Registry
Now that we have a brief understanding of peristant interpretters,
we discuss how Apache::Registry works (at a pretty high level). Then
we go into common traps and pitfalls of running CGIs under it,
discuss clean coding practices, and explain why those pitfalls
exist.
Overview of Apache API and Architecture
We get down and dirty and discuss the server architecture (the
1.3.x pre-forking model only, though I'll mention 2.x and other
MPMs). Working up from our brief view of the server, we discuss the
various phases the API exposes us to and what each is for.
Illustrated by examples of which common modules run where and why.
And of course giving the C and Perl handler names for each phase. We
also mention the API's records/objects and give a few details on
them.
Response/Content Handlers
We now discuss the all important content phase and the Apache
request object (95% of all handler you write will be in this phase).
The majority of the code snippets will be here, illustrating the
standard look of a mod_perl handler and the special considerations
mod_perl requires. We also discuss the Perl configuration directives
in detail so we can run the modules/handlers we create. This is
currently the largest bit of the talk.
Question and Answer
Obvious.
Right now my weighting leans heavily toward explaining the API and
writing custom handlers. Are more people interested in just speeding up
their portable CGI code? Should I explain the traps in real detail or
just mention they exist and say 'persistance' and 'forking' for answers?
Or do we want a "How to install mod_perl in 90,000 different situations"
talk? Heh. I can also add in configuring for multi-tier and load
balancing, caching techniques, debugging, load testing, porting mod_perl
modules to C, or other performance related issues if people want them.
What do you guys want? (I should have asked this in detail before I
started writing :)
P.S. I appologize for any bad gammar or incoherent statements, it's
almost 4:00am...
More information about the kw-pm
mailing list