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.