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.
