Re^6: RFC: Apache2::CloseKeepAlive

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" :-)

Comment on Re^6: RFC: Apache2::CloseKeepAlive

Replies are listed 'Best First'.
Re^7: RFC: Apache2::CloseKeepAlive by jethro (Monsignor) on Aug 28, 2009 at 22:18 UTC
Maybe it's the word "database" that has spooked you No, it was the image in my mind of an install routine doing a search on a big disk partition and a clueless admin sitting there wondering what on earth this install script is doing. I've brought up all those (often farfetched) examples not as specific grievances you should protect against, but just to show there are reasons why (some?) people want an install to be just an install. This is independent of the actual module. If I installed a library or module that could cache sound files I also wouldn't like the install routine to automatically search the disk for sound files and creating the cache. An application program maybe, but a module/library, definitely not. Or a module that creates rainbow tables for AES should not start to build the rainbow tables as part of the install, obviously ;-) Naturally, if you need a database for testing, that is different. But in that case the problem is that you have to provide the test data yourself as you can't expect any fitting test data on the machine. So if you have to provide the test data anyway, why make a time wasting and installation dependant search for additional data if you already got the test data? To make an example: I remember that there was a perl module for connecting over the network. For the testing it actually tried to access the internet. Which was bad, because it didn't test only the module. It also tested the whole network, the firewall and the internet connection, extrinsic features to the module. An installation to fail because of external circumstances like a turned off router sends a wrong signal. If your testing depends on data you find on the machine you get into the same danger of testing something external to your module. For example corrupted html files on the web server should not lead to test failures for your module	[reply]

Replies are listed 'Best First'.

Re^7: RFC: Apache2::CloseKeepAlive
by jethro (Monsignor) on Aug 28, 2009 at 22:18 UTC

Maybe it's the word "database" that has spooked you

No, it was the image in my mind of an install routine doing a search on a big disk partition and a clueless admin sitting there wondering what on earth this install script is doing.

I've brought up all those (often farfetched) examples not as specific grievances you should protect against, but just to show there are reasons why (some?) people want an install to be just an install. This is independent of the actual module. If I installed a library or module that could cache sound files I also wouldn't like the install routine to automatically search the disk for sound files and creating the cache. An application program maybe, but a module/library, definitely not. Or a module that creates rainbow tables for AES should not start to build the rainbow tables as part of the install, obviously ;-)

Naturally, if you need a database for testing, that is different. But in that case the problem is that you have to provide the test data yourself as you can't expect any fitting test data on the machine. So if you have to provide the test data anyway, why make a time wasting and installation dependant search for additional data if you already got the test data?

To make an example: I remember that there was a perl module for connecting over the network. For the testing it actually tried to access the internet. Which was bad, because it didn't test only the module. It also tested the whole network, the firewall and the internet connection, extrinsic features to the module. An installation to fail because of external circumstances like a turned off router sends a wrong signal. If your testing depends on data you find on the machine you get into the same danger of testing something external to your module. For example corrupted html files on the web server should not lead to test failures for your module

[reply]