NAME

       ic_mod_perl -- Run Interchange entirely inside Apache/mod_perl

SYNOPSIS

         # Add to Apache httpd.conf:
         PerlRequire /usr/lib/interchange/bin/ic_mod_perl
         PerlChildInitHandler Vend::ModPerl::child_start
         PerlChildExitHandler Vend::ModPerl::child_end
         <Location /ic>
             SetHandler perl-script
             PerlHandler Vend::ModPerl
             PerlSendHeader Off
             PerlSetupEnv On
         </Location>

DESCRIPTION

   Benefits
       •   Possibly better stability, especially on non-Linux platforms where Perl signals are often buggy.

       •   Use less memory total; don't have preforked Apache and Interchange daemons. Adds about 8 MB more to a
           typical  Apache/mod_perl  child  process,  for  a  total of, say, 32 MB per Apache child process. But
           standalone Interchange usually has 3 processes: an Interchange child process (~24 MB), an httpd child
           (~24 MB), and a link CGI (~1 MB), so it's actually a decent savings in total memory used.

       •   Speed (ranging from slightly faster to the same on heavy pages,  to  10  hits/sec.  faster  on  empty
           pages).

       •   Debugging -- delve into bowels with Apache::Status.

       •   Easier coexistence with other mod_perl code and libraries.

       •   Can coexist with standalone Interchange codebase without problems.

       •   Administrative ease (for sysadmins who know Apache but not Interchange).

   Drawbacks
       •   Interchange  runs  as  web  server  user, which in a standard system is usually apache or www, so you
           wouldn't want to share that Apache installation with untrusted user CGIs, PHP,  etc.  as  they  could
           read any Interchange files, including DSNs, userdb, etc.

       •   Apache  needs  to  be  dedicated, or very closely watched because all mod_perl stuff runs in the same
           interpreter, and lots of mod_perl code doesn't use Safe.

       •   How do you scale to multiple app servers in this configuration?

           •   Hardware or software port redirector

           •   Tux CGI front-end redirector like tlink

           •   Separate lightweight Apache (no modules) that proxies /ic requests

   Ideal system setup
       Use Tux to serve images & static content, and a  dedicated  Apache  for  Interchange  running  under  the
       'interch' user and with no UserDir, CGI, PHP, etc. enabled and an empty DocRoot.

CAVEATS

       •   Watch  out for differing Storable versions in sessions when switching between standalone and mod_perl
           runs!

BUGS

       •   Haven't yet implemented form/multipart submissions.

       •   Don't yet handle TolerateGet.

       •   Don't yet handle MiniVend 3 style GETs (mv_session_id;mv_arg;mv_pc)

       •   URIs must follow format "/ic/catalogname/page...", where /ic is customizable but  must  only  be  one
           "directory" deep (i.e., no slashes).

AUTHOR

       Jon Jensen <jon@icdevgroup.org>, March 2002

perl v5.14.2                                       2012-05-01                                    IC_MOD_PERL(1p)