Front page | perl.perl5.porters |
Postings from May 2013
On Fri, 24 May 2013 14:03:47 +0200, Johan Vromans <jvromans@squirrel.nl> wrote: > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes: > > > The core decision is not to deprecate CGI as a module, it is trying to > > remove the bundling with CORE. > > Never underestimate the benefits of being a core module. I don't > As a core module, CGI.pm is guaranteed to be there, and it will work. > If you want something quick and simple, CGI.pm is the obvious choice. I already hit this situation with Text::Soundex. Is still stand behind my vote. > As a CPAN module, you'll have to install it yourself, if you can, and > there's no guarantee it will work. Or install it as a prepackaged distribution asset. Most if not all vendors have *a lot* of perl packages as prepacked rpm/deb/sd/whatever available. It might even be an even higher guarantee to work in your environment. If you use perlbrew in order not to mess with system-perl this problem doesn't exist at all. If you depend on a hosting provider, having perl without *any* web-support is useless, so the provider will have to do something anyway. > And, if you want something quick and simple, use CPAN search and find > yourself drowned in houndreds of CGI handling modules. Good luck finding > one that suits your needs. And works. > > The bottom line is: Do we want to ship perl such that it is easy to get > started with simple web applications? If so we either need to include > CGI.pm in the core, or put it on CPAN *and*make*sure*it*works. > No change in maintenance burden. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/Thread Previous | Thread Next