Greetings,

I have been using Perl extensively over the last couple years, mostly in
the form of CGI applications/libraries/scripts that run under Apache
servers.  I am currently migrating my code to run under mod_perl, and
after looking at the various readmes, I have a few questions.

First, a quick overview on my design and coding style:

I believe that I have taken the care to write my code
somewhat elegantly and with an eye on proper structured programming
techniques and maintainability.  Since I am relatively new to the language
(introduced to in 1998) I started off with Perl 5 and its worldview, which
means among other things that I use object-oriented features extensively,
do not use the Exporter, always use strict, make liberal use of real
references and subroutines/methods, create my own modules for code reuse,
and so-on.  While Perl affords me many ways to do something, I look for
the best compromise between maintainability and speed.  I do my best not
to obfuscate, and thereby I usually name my variables even if I don't have
to (for example, using "shift(@_)" instead of "shift").

In anticipation that I would be migrating to mod_perl in the near future,
I did what I could to read up on its more strict requirements relative to
the CGI environment.  Where possible, I used lexical (my) variables for
everything possible, including file-scope "constants".  Any
non-"special" global variables are stored inside my objects, which are
passed as arguments and stored in lexicals.  I always use strict.

Now some questions that I hope some of you can help me with.  Hopefully
each has short answers.

1. Since I imagine that I would be running inside Apache::Registry (I
don't own the machine, someone else sets up the server), does it take care
of reloading any modules that I "use" or "require" when they change on
disk?  I read that this doesn't happen under mod_perl in general, but it
would be useful since I often update my code and I can't restart the
server.

2. The POD for Apache::Registry says that it doesn't like __END__ and
__DATA__ tokens.  So what affect do these actually have if left in?  Does
Perl just try to parse what came afterwards as if they weren't there, or
are there other issues?  (Note: I don't use these for filehandles.)  I do
not use main:: at all.

3. Related to the above, I use the Net::SMTP module by Graham Barr quite a
lot to implement send e-mail (instead of sendmail) because it gives me
feedback on whether the send actually worked, is faster(?), and it runs on
any host system.  However, this module uses tokens like __END__, so I'm
wondering if it would break under mod_perl.  In preliminary testing of
this and my own modules, the mail seems to send fine, but I'm concerned
about longetivity.

4. Since I have been avoiding globals (eg: "Q::varname") so far, I'm not
sure where and how to use them to work the way I need.  The only time I
would need globals (I assume) is if I want to use "singletons".  And yes,
I know about Class::Singleton, but I stopped using it due to global fears.
And so:

  a. How do I set up and clean up a "static" variable that is shared by
multiple instances of a class that are in the same server thread and not
seen by other threads (the same functionality that CGIs take for granted).
Currently I use one object to create the others, thereby copying
references, but I would prefer not to.

  b. How do I set up and (when needed) clean up a "persistant" variable
that would be shared by multiple server threads, such as an open database
connection.  Related to this, would I be able to use a DBI object as this
persistant variable, or would I have to use something else.

I am guessing that (b) is probably a whole discussion in itself, and
perhaps there's a book on it?  (I already have Oreily's "Advanced Perl"
and "Writing Apache Modules...", although know not where to look in them.)

So I will leave off asking more questions for the moment.

Any help would be greatly appreciated, as these issues have been pressing
on me for many months (at least #4 was).

Thanks a lot in advance,

// Darren Duncan

Reply via email to