Michael G Schwern wrote on 12 November 2004 21:48 > On Fri, Nov 12, 2004 at 07:00:17PM -0000, Orton, Yves wrote: > > I disagree. Having modules in the core is one of the few > ways to guarantee > > that the module will be uniformly available. > > Its very unlikely to get into the core.
That's really too bad. > > To summarize the (unofficial?) core policy on modules (unless > something changed while I wasn't looking), new core modules are considered if: Well if the policy prevents a fix like this going in then the policy is B0RKED and should be resigned to the dustpan of history. Let me give you an example: There was this little hack that meant that somebody with waaaaaaaay too much time on their hands could cause DDOS attack on perl. Despite the fact that this matter really only affected a) web sites using perl and b) would slow down the overall hash implementation for everyone and c) could _easily_ be worked around by users themselves or by a simple patch to CGI the perl5porters community decided that resolving the matter was a top priority. Now we have a problem a that poorly written scripts can do the same or worse. Not only that but we have evidence that the matter negatively affects the uptake of Perl in the Win32 market, one of the largest computing markets around. Yet you don't think its important enough? > There's also various projects to come up with lists of important modules. > Phalanx is one. The creeping tar pit that is the Perl SDK project was > another. Various OS vendors providing packaged modules is yet another. > > There are any number of ways to make a module look more legit > than just sticking it in the core. IMO this is crap. Nobody in the hosting market gives a toss about Phalanx, or just about anything that doesn't say "100% offical approved and good". Hell there are masses of places out there that wont even install DBI or CGI because they arent/werent part of core for the version they have installed. Yves
