Perl: the Markov chain saw | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
What happens if there's a security bug in an underlying module which makes it necessary for you to upgrade it? You have disqualified yourself from the target user if have multiple versions of the same things install, and you have a clue about security. 1. Find every instance of that module and update it in place, making sure that you break none of the applications in the process.The part about "making sure you break none of the applications" is required step for all applications that use the module, whether you upgrade it one place or multiple places. And that's where most of the work. The "find every instance" would be a simple "find", if you didn't already know by memory or from documentation. 2. Wait for all applications to release a new version with the upgraded module, which can take days to months, leaving you vulnerable in the meantime. This could be solved be the infrastructure. Remember the "auto generated packages"? When a new module is published to CPAN the package depends on, a new bundle could be available immediately. (Perhaps because the bundles would be generated on the fly or with smart caching). Like Linux distro packaging systems, the bundle name might include a revision in addition to the version, indicating that the bundled prereqs have been updated. Additionally, encouraging the practice of using "private" versions of modules will lead to brittle applications which assume they know exactly which kind of environment they're working in, as well as a plethora of "tweaked" versions of modules for each app.Remember the design? The distributions would be regular CPAN distributions with regular dependencies. I'm just talking about generating an additional alternate view for end users. Since the authors are CPAN uploaders, they won't suddenly lose a clue about good software practices. Frankly, I don't consider [the shared web hosting] usage scenario important enough to make things harder for the rest of us. Ouch. This attitude of not caring about end users may do something to explain why several PHP applications now at the top of my list for features and end-user ease-of-use, even though I would prefer a Perl solution: osCommerce, PhpPgAdmin, PhpBB, PhpAds, WordPress, Drupal. The net effect is that I'm now learning some PHP to light customizations to osCommerce and Drupal, because as a pragmatic user, they already have extensions written for them that do about everything I want. Unless I've missed something in my research, Perl's got some catching up to do in the end-user killer web-app category, and I think some infrastructure focused on that could really help. The result would actually be better, because in the background we would be using many of the well-documented, well-coded and well-tested we're already familiar with from CPAN. In reply to Re^2: A Vision for Easy Web Application Deployment for Perl
by markjugg
|
|