You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Bruce W. Hoylman" <bw...@indra.com> on 2002/01/06 23:14:56 UTC

Apache::RPC::Server questions

Ciao!

Looking at RPC::XMl::Server and subsequently the Apache::RPC::Server 
subclass I see that methods are implemented via passing a code ref to a 
named or anonymous subroutine that implements the actual method logic. 
Given the persistent nature of perl in an Apache/modperl environment, is 
there any inherient problems this might cause in a complex method, other 
than those caused via bad modperl coding practices?

The first thing I thought about is the dangers of closures and the 
potential for persistent variables and data between requests.  Will the 
avoidance of using any type of globally scoped variables within this 
method defining subroutine be enough to avoid these types of problems? 
Does this method defining subroutine ever go out of scope during the 
life of a modperl process, therefore freeing lexicals and other local 
data and data structures?  Do I need to do any explicite destruction of 
objects prior to exiting the subroutine, for example?

I may need to make database accesses from within the method.  Will 
Apache::DBI still work within this framework?

The documentation indicates it is dangerous to change package namespace 
within the method defining subroutine.  Does this apply to the 'use' or 
'require' of modules within the subroutine as well?

Frankly, I'm so used to writing the actual handler subroutine and 
supporting modules that I'm feeling a little out of my element given the 
method definition paradigm the RPC::XML::Server is introducing.

Thanks for any information you might be able to provide on this matter.

Peace.