[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