in reply to RFC: Apache2::CloseKeepAlive

Probably SoPW would have been a better place for your node.

Module::Build is fine, a good idea is to use Module::Starter (and Module::Starter::Smart) to create the skeleton of a CPAN-ready module automatically

I must confess I don't know what you mean with GP Perl. It can't be Perl Genetic Programming System, right?

I don't think a module installation should ask questions. Questions should be asked by the program that uses a module.

Replies are listed 'Best First'.
Re^2: RFC: Apache2::CloseKeepAlive
by cmac (Monk) on Aug 28, 2009 at 02:06 UTC
    SoPW would certainly have gotten this post more notice! I was influenced by the stuff in the header of Meditations about "sounding board" and "RFC", and I'm too lazy to try to move it now.

    I use GP as a standard abbreviation for general purpose. The general purpose Perl library is typically headed at /usr/local/lib/perl5 on unix systems.

    People on the mod_perl mailing list have talked me into letting the module and accompanying database-building script go into the GP perl library and standard 'script' or 'bin' location, respectively.

    The install process will (quietly) run said accompanying script. It builds a database that maps .htm(l) filenames to the number of .jpg files called out by each. Module::Build plus the CPAN config have good features for various kinds of files, but they don't include a place for data files.

    The inclusion of Apache::Test will probably let the Build process know the location of Apache. Probably it could be set up to make (if necessary) a 'var' subdirectory in the Apache directory, and put the database there. Is that better than asking the user where to put it?

    That seems like a good thing to do, since the info in the DB is based on the sibling 'htdocs' directory. Actually putting the DB in htdocs doesn't appeal to me.

    Thanks for your interest,
    cmac
[reply]

      Maybe I'm too conservative here, but as sysadmin I don't like libraries/modules that do more than install when I tell them to install.

      For example, I might not have apache and/or the jpegs and html files installed when I install your module.
      I might not want all htmls and jpegs included in your database.
      This could be DOM0 of a virtual setup and only the clients should have those databases.
      I might have more than one apache installed, only one should get the treatment.
      Maybe I just want to look at the module to evaluate it for a different machine.
      Maybe I have a non-standard installation that will let your script do something bad if not adapted.
      Maybe I have a few terabytes of jpegs and html so that your database would overflow the /var space.
      The machine might have some security setup where the unexpected creation of files in specific directories leads to emergency shutdown of the machine.
      The sysadmin might have very different ideas about where your database should be put.
      The installation might have to be redone a few times (maybe because it is part of a bigger installation script that doesn't work correctly) and it wastes 20 minutes every time.
      Or there were some changes necessary in the database and every reinstall of a new version of your module will overwrite those changes
      Maybe there are hundreds of machines all of which get the same identical library installation, but only one of the machines will be a web server. And all have access to a big html-data directory through (traffic-heavy) NFS.

      Calling your init script should be done explicitly by anyone using your module. He should know what to expect, should know what your init script does before he calls it. You should put a text something like 'Call the script with parameters a and b to initialize the database before first use. This will do the following:...' into the usage description of the pod documentation.

      All this IMHO

[reply]
        The DB-building program can be re-run at any time, and should be after changes to the site. The only purpose in running it, as part of the installation process, is that there has to be a DB to run the tests that everyone expects a CPAN module to have. You as installer probably never know that the program is run.

        I don't know what to do with "I might not want all htmls and jpegs included in your database". First, at that point it's your database, not mine. Second, the database consists simply of a hash from .html filenames to the number of .jpg's each calls out. Why would anyone care whether all the files that are linked to the front page are included?

        Such a DB is not likely to "overflow the /var space". What does that mean anyway?

        How can an Apache2 installation be so non-standard that the DB-making program can't follow the links among its .html files? Keeping a script from "doing something bad" is a normal part of module development and deployment.

        "the unexpected creation of files in specific directories leads to emergency shutdown of the machine" sounds like "turn off your anti-virus software before installing"?

        Half the people (1 of 2 :-) say "I don't think a module installation should ask questions" and the other half say "The sysadmin might have very different ideas about where your database should be put". What's a poor module-installer-designer to do? It's not possible to ask a question to determine whether any questions should be asked!

        It takes a few seconds to run the DB-making script on my site, not 20 minutes. But I'll put in a check that if the DB already exists, it won't run the script.

        You probably don't like CPAN modules for which the testing phase takes minutes.

        "there were some changes necessary in the database": the DB reflects the contents of the site. It and CloseKeepAlive are a closed (private) system. "Changes become necessary" only when the site changes.

        Installing a module intended for Apache servers, on machines that aren't Apache servers, is something I hadn't thought of. I suggest you not include CloseKeepAlive in your general distribution of CPAN modules.

        The first thing that Apache::Test does is to ask "where is your Apache server?" If that question doesn't lead to starting up a test server, the (rest of the) tests don't get run. So I guess I should move the running of the DB-making script to the testing phase. Does that help with your concerns?

        The pod docs will be updated to cover running the DB-making script. The posted page was just to give people an idea what CloseKeepAlive is about.

        Despite all that, thanks for replying. Each correspondent contributes things to the packaging, testing, and installation. Except that "whether to ask where to put the DB" looks like a true conundrum.
[reply]

In Section Meditations