Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ic_mod_perl(1p) [debian man page]

IC_MOD_PERL(1p) 					User Contributed Perl Documentation					   IC_MOD_PERL(1p)

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
       o   Possibly better stability, especially on non-Linux platforms where Perl signals are often buggy.

       o   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.

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

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

       o   Easier coexistence with other mod_perl code and libraries.

       o   Can coexist with standalone Interchange codebase without problems.

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

   Drawbacks
       o   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.

       o   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.

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

	   o   Hardware or software port redirector

	   o   Tux CGI front-end redirector like tlink

	   o   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

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

BUGS

       o   Haven't yet implemented form/multipart submissions.

       o   Don't yet handle TolerateGet.

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

       o   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-01-23							   IC_MOD_PERL(1p)

Check Out this Related Man Page

Apache::XMLRPC(3pm)					User Contributed Perl Documentation				       Apache::XMLRPC(3pm)

NAME

       Apache::XMLRPC - serve XML-RPC requests from Apache

SYNOPSIS

	  ##
	  ##  Directives for your Apache config file.
	  ##
	  <Location /RPC2>
	     SetHandler perl-script
	     PerlHandler Apache::XMLRPC
	     PerlSetVar XMLRPC_Config /usr/local/apache/xml-rpc/services
	  </Location>

	  ##
	  ##  In the 'services' file referenced above by 'XMLRPC_Config'
	  ##
	  sub foo {
	     ...
	  }

	  sub bar {
	     ...
	  }

	  $map = {
	     foo   => &foo,
	     bar   => &bar,
	  };

	  1;

DESCRIPTION

       Apache::XMLRPC serves Userland XML-RPC requests from Apache/mod_perl using the Frontier::RPC2 module.

       Configuring Apache::XMLRPC to work under mod_perl is a two step process.  First, you must declare a "<Location>" directive in your Apache
       configuration file which tells Apache to use the content handler found in the Apache::XMLRPC module and defines a variable which tells the
       module where to find your services.  Then, you must define the services.

   Apache Configuration
       Apache configuration is as simple as the "<Location>" directive shown in the synopsis above.  Any directive allowed by Apache inside a
       "<Location>" block is allowed here, but the three lines shown above are required.  Pay close attention to the 'PerlSetVar XMLRPC_Config
       ...' line as this is where you tell Apache where to find your services.	This file may reside anywhere accessible by Apache.

   Defining Services
       To actually define the XML-RPC routines that will be served, they must reside in the file referenced by the 'PerlSetVar XMLRPC_Config ...'
       directive in the Apache configuration file.  In this file you may place as many Perl subroutines as you like, but only those which are
       explicitly published will be available to your XML-RPC clients.

       To publish a subroutine, it must be included in the hash reference named $map (the hash reference must have this name as this is the
       variable that the Apache::XMLRPC passes to Frontier::RPC2::serve to actually service each request) The hash reference must be defined in
       this "services" file.

       The keys of the hash are the service names visible to the XML-RPC clients while the hash values are references to the subroutines you wish
       to make public.	There is no requirement that the published service names match those of their associated subroutines, but it does make
       administration a little easier.

SEE ALSO

       perl(1), Frontier::RPC2(3)

       <http://www.scripting.com/frontier5/xml/code/rpc.html>

AUTHOR

       Ed Hill <ed-hill@uiowa.edu> is the original author.

       Tim Peoples <tep@colltech.com> added a few tweaks and all the documenation.

perl v5.10.1							    2011-04-05						       Apache::XMLRPC(3pm)
Man Page