The only thing that CloseKeepAlive ever does is to allow the connection to be kept alive or not. Other elements of Apache also take part in this decision. Only very-low-level network diagnostics would care about the difference.
The DB-making script doesn't care about static vs. dynamic generation, it uses LWP to fetch the pages without regard for how they're generated. But your point is well-taken and I'll add exclusion mechanisms to the DB-making program, namely "don't process this/these file(s)" and "don't process files in/below this/these directory/ies".
The script is OK w/r/t back-references because my web site has links pointing everywhich way from almost everywhere. Probably I haven't "thought of everything else and eliminated every possible bug". Does a "simple install" include testing? If so, I'll stipulate that I haven't.
The DB built during testing will in fact be in the 'blib' folder of the build directory. The question is whether this DB wants to be copied out into the site along with the module, docs, and building script, if the testing passes and the install phase occurs. Lots of people would say "yes" because this makes the module more "ready to go out of the box", which is considered a big plus these days. You're obviously saying "no". I need more data to decide.
If such copying is done, it is noted in the install log, which (at least in a formal sense) notifies the person running the test so that he/she has slightly less grounds to be surprised.
If someone wants to evaluate a module in the sense of reading about it, including looking at the source, he/she can do that on CPAN. The presentation is better than perldoc or man files created during installation.
In the general case (though maybe not for this module) good testing definitely includes "lots of fancy routines, that could error out or even crash, as part of the installation".
Apache::Test will fire up a test server for my tests to use, and it will have something in its ServerRoot directory. Typically this will be the content of the web site with which CKA will be used. If the contents of ServerRoot won't test CKA very well, maybe the testing routines can add content that comes with the package to the test server, in such a way that it does not become a permanent part of the web site. I can't know whether that's possible without some digging, but I'll try.
If this step is taken, the DB will be deleted so that it's not copied out for retention. If this step isn't possible, all that can be done is to note that the module hasn't been tested very well.
Maybe it's the word "database" that has spooked you. It conjures up Oracle and PostGreSQL and who knows what all? A simple lookup hash from filename to number of JPG files isn't worthy of the name, so let's just call it a "table" :-)
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.