Mailing List Archive

On Thu, May 23, 2013 at 7:50 PM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:
> I think it's time to seriously consider removing CGI.pm from the core

+1

--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

> I think it's time to seriously consider removing CGI.pm from the core
> distribution.  


+1

Mark

On 5/23/13 7:50 PM, Ricardo Signes wrote:
>
> I think it's time to seriously consider removing CGI.pm from the core
> distribution.

+1 ... but at the same time, I special shout-out to Lincoln Stein for
this historically important technology!

On Fri, May 24, 2013 at 1:50 AM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:
> I think it's time to seriously consider removing CGI.pm from the core
> distribution. It is no longer what I'd point *anyone* at for writing *any*
> sort of web code. It is in the core, as far as I know, because once it was the
> state of the art, and a major reason for many people to use the language.

AFAIK, it's in core because perl 4 shipped with all then-known
libraries and CPAN wasn't founded until a year after perl 5 came out
:-|

> I
> don't think either is true now. Finally, if you need CGI, it's easy to install
> after installing perl, just like everything else we've dropped from the core
> distribution.

I think the "it will be installed everywhere" is the one valid reason
why one may want to use CGI.pm.

> In the past two years, all my interactions with CGI.pm have been to fix bugs or
> send pull requests to quiet it from making noise in the core. I expect others
> here have had the same experience.
>
> Are there any arguments out there to compel me to feel otherwise about this?

Another datapoint: CGI.pm is very much facing the hostile internet.
That means that any security issue in CGI is currently our problem
too.

Leon

* James E Keenan <jkeen@verizon.net> [2013-05-23T21:19:53]
> On 5/23/13 7:50 PM, Ricardo Signes wrote:
> >
> >I think it's time to seriously consider removing CGI.pm from the core
> >distribution.
>
> +1 ... but at the same time, I special shout-out to Lincoln Stein
> for this historically important technology!

Indeed! My world would be a different place without CGI.pm, for sure.

--
rjbs

On Thu, 23 May 2013 19:50:55 -0400, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:

> I think it's time to seriously consider removing CGI.pm from the core
> distribution. It is no longer what I'd point *anyone* at for writing *any*
> sort of web code. It is in the core, as far as I know, because once it was the
> state of the art, and a major reason for many people to use the language. I
> don't think either is true now. Finally, if you need CGI, it's easy to install
> after installing perl, just like everything else we've dropped from the core
> distribution.
>
> In the past two years, all my interactions with CGI.pm have been to fix bugs or
> send pull requests to quiet it from making noise in the core. I expect others
> here have had the same experience.
>
> Are there any arguments out there to compel me to feel otherwise about this?

I suggested removal of CGI back in 2001 (I checked). I see no reason
whatsoever to keep it in CORE (other than people expecting it to be
in CORE)

++ for removal

--
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/

On 24 May 2013 08:46, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Thu, 23 May 2013 19:50:55 -0400, Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
>
>> I think it's time to seriously consider removing CGI.pm from the core
>> distribution. It is no longer what I'd point *anyone* at for writing *any*
>> sort of web code. It is in the core, as far as I know, because once it was the
>> state of the art, and a major reason for many people to use the language. I
>> don't think either is true now. Finally, if you need CGI, it's easy to install
>> after installing perl, just like everything else we've dropped from the core
>> distribution.
>>
>> In the past two years, all my interactions with CGI.pm have been to fix bugs or
>> send pull requests to quiet it from making noise in the core. I expect others
>> here have had the same experience.
>>
>> Are there any arguments out there to compel me to feel otherwise about this?
>
> I suggested removal of CGI back in 2001 (I checked). I see no reason
> whatsoever to keep it in CORE (other than people expecting it to be
> in CORE)
>
> ++ for removal

Ditto.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

Leon Timmermans wrote:
> On Fri, May 24, 2013 at 1:50 AM, Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
>> I think it's time to seriously consider removing CGI.pm from the core
>> distribution. It is no longer what I'd point *anyone* at for writing *any*
>> sort of web code. It is in the core, as far as I know, because once it was the
>> state of the art, and a major reason for many people to use the language.
>
> AFAIK, it's in core because perl 4 shipped with all then-known
> libraries and CPAN wasn't founded until a year after perl 5 came out
> :-|
>

This is probably the reason it is still in.

+1 for removal

I don't use Perl for webhosting, so none of the CGI stuff or numerous DB
modules I have ever used.

Hello

2013/5/24 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
>
> I think it's time to seriously consider removing CGI.pm from the core
> distribution. It is no longer what I'd point *anyone* at for writing *any*
> sort of web code. It is in the core, as far as I know, because once it was the
> state of the art, and a major reason for many people to use the language. I
> don't think either is true now.

Many people still use programs that use CGI.pm, for ex. from NMS
collection. And CGI.pm is easiest to start with.

> Finally, if you need CGI, it's easy to install
> after installing perl, just like everything else we've dropped from the core
> distribution.

It would not be easy to do on web hosting which does not has
possibility of installing modules from CPAN. Also currently CGI.pm
requires FCGI which requires compiler which frequently is not
installed.
>
> In the past two years, all my interactions with CGI.pm have been to fix bugs or
> send pull requests to quiet it from making noise in the core. I expect others
> here have had the same experience.

I use CGI::Applications (mostly for old programs), it uses CGI.pm.
Also if I need a very simple web program, I use CGI.pm directly.


--
Alexandr Ciornii, http://chorny.net

On 24 May 2013 11:06, Alexandr Ciornii <alexchorny@gmail.com> wrote:
> Hello
>
> 2013/5/24 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
>>
>> I think it's time to seriously consider removing CGI.pm from the core
>> distribution. It is no longer what I'd point *anyone* at for writing *any*
>> sort of web code. It is in the core, as far as I know, because once it was the
>> state of the art, and a major reason for many people to use the language. I
>> don't think either is true now.
>
> Many people still use programs that use CGI.pm, for ex. from NMS
> collection. And CGI.pm is easiest to start with.
>
>> Finally, if you need CGI, it's easy to install
>> after installing perl, just like everything else we've dropped from the core
>> distribution.
>
> It would not be easy to do on web hosting which does not has
> possibility of installing modules from CPAN. Also currently CGI.pm
> requires FCGI which requires compiler which frequently is not
> installed.

Maybe the consequence of this would be that hosting services start
adopting a more progressive approach to this subject.

Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Fri, May 24, 2013 at 12:06:49PM +0300, Alexandr Ciornii wrote:
> Hello
>
> 2013/5/24 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
> >
> > I think it's time to seriously consider removing CGI.pm from the core
> > distribution. It is no longer what I'd point *anyone* at for writing *any*
> > sort of web code. It is in the core, as far as I know, because once it was the
> > state of the art, and a major reason for many people to use the language. I
> > don't think either is true now.
>
> Many people still use programs that use CGI.pm, for ex. from NMS
> collection. And CGI.pm is easiest to start with.

I'm aware of NMS, and that it was deliberately targeting CGI.pm to promote
modules, code re-use, and not screwing up security related issues things
like parameter parsing.

Presumably every web framework out there is having to deal with form
parameters and URI escaping/unescaping. And avoid making goofs. And deal
with changes like ';' instead of '&'.

Is there something small which just does this?
Should the core be providing such foundation functionality?
(Although then you get to HTML entities, which starts to get big?)

> > Finally, if you need CGI, it's easy to install
> > after installing perl, just like everything else we've dropped from the core
> > distribution.
>
> It would not be easy to do on web hosting which does not has
> possibility of installing modules from CPAN. Also currently CGI.pm
> requires FCGI which requires compiler which frequently is not
> installed.

Yes, this is strange. The core merrily ships CGI.pm without FCGI, yet the
CPAN version of CGI.pm insists that FCGI is a hard dependency. Clearly the
dependency can't be a hard dependency, else the version shipped by the core
wouldn't work.

And, as you say, the dependency makes it hard to install (or upgrade) CGI.pm
on a system without a compiler.

What stops CGI.pm making FCGI optional? Or splitting out the FCGI support
into a separate distribution?

> > In the past two years, all my interactions with CGI.pm have been to fix bugs or
> > send pull requests to quiet it from making noise in the core. I expect others
> > here have had the same experience.
>
> I use CGI::Applications (mostly for old programs), it uses CGI.pm.
> Also if I need a very simple web program, I use CGI.pm directly.

But you have to install CGI::Applications from CPAN. So it shouldn't be
any harder to install CGI.pm and CGI::Applications from CPAN.

Nicholas Clark

On Fri, 24 May 2013 12:06:49 +0300, Alexandr Ciornii
<alexchorny@gmail.com> wrote:

> Hello
>
> 2013/5/24 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
> >
> > I think it's time to seriously consider removing CGI.pm from the core
> > distribution. It is no longer what I'd point *anyone* at for writing *any*
> > sort of web code. It is in the core, as far as I know, because once it was the
> > state of the art, and a major reason for many people to use the language. I
> > don't think either is true now.
>
> Many people still use programs that use CGI.pm, for ex. from NMS
> collection. And CGI.pm is easiest to start with.

For extremely simple and easy things I also still use CGI, but I still
vote for CORE-removal. CPAN is good-enough. Really.

The core decision is not to deprecate CGI as a module, it is trying to
remove the bundling with CORE.

> > Finally, if you need CGI, it's easy to install after installing perl,
> > just like everything else we've dropped from the core distribution.
>
> It would not be easy to do on web hosting which does not has
> possibility of installing modules from CPAN. Also currently CGI.pm
> requires FCGI which requires compiler which frequently is not
> installed.
>
> > In the past two years, all my interactions with CGI.pm have been to fix bugs or
> > send pull requests to quiet it from making noise in the core. I expect others
> > here have had the same experience.
>
> I use CGI::Applications (mostly for old programs), it uses CGI.pm.
> Also if I need a very simple web program, I use CGI.pm directly.

--
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/

On Fri, 24 May 2013 11:06:49 +0200, Alexandr Ciornii
<alexchorny@gmail.com> wrote:

> 2013/5/24 Ricardo Signes <perl.p5p@rjbs.manxome.org>:
>>
>> Finally, if you need CGI, it's easy to install after installing perl,
>> just like
>> everything else we've dropped from the core distribution.
>
> It would not be easy to do on web hosting which does not has
> possibility of installing modules from CPAN. Also currently CGI.pm
> requires FCGI which requires compiler which frequently is not
> installed.

I ask for this to be considered a blocker for uncoring CGI.pm. As much as
i dislike it, many people are in environments where no compiler is
available (welcome to corporate policy) and will have a very rude
awakening many years in the future when their Perl is upgraded.

--
With regards,
Christian Walde

demerphq <demerphq@gmail.com> writes:

>> It would not be easy to do on web hosting which does not has
>> possibility of installing modules from CPAN. Also currently CGI.pm
>> requires FCGI which requires compiler which frequently is not
>> installed.
>
> Maybe the consequence of this would be that hosting services start
> adopting a more progressive approach to this subject.

That would have been so several years ago. I don't think it works like
that nowadays.

Hosting provider: Here's your system. Good luck.
Client: Hey, I need perl!
Hosting provider: Perl's on the system.
Client: But I need to install modules to get my web application going.
Hosting provider: Can't do. Please use php / ruby / ... instead.

-- Johan

"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.

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.

As a CPAN module, you'll have to install it yourself, if you can, and
there's no guarantee it will work.

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.

-- Johan

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/

"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:

> If you depend on a hosting provider, having perl without *any*
> web-support is useless, so the provider will have to do something
> anyway.

See my other mail.

-- Johan

On Fri, May 24, 2013 at 02:03:47PM +0200, Johan Vromans wrote:

> Never underestimate the benefits of being a core module.

Yes. You now have the perceived advantages of being "blessed", "supported"
and "installed". However true those statements aren'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.

This is not strictly true, as I believe that at least one point FreeBSD
removed it from their base distribution of perl. But I don't know if that
was a "glitch", later resolved by removing the need for perl to be in the
base distribution (and hence the reason why they really wanted their perl
to be smaller).

But it's as good as true, because I'm not aware of any other OS or vendor
doing something similar. And likely the places where this matters aren't
running FreeBSD.

> As a CPAN module, you'll have to install it yourself, if you can, and
> there's no guarantee it will work.

I'm having trouble parsing the last "it". In that, if you can install it
(the module), then I'm failing to envisage a situation where the code
wouldn't work, as the code is identical. Any more (or less) than your
hosting provider (or their OS "vendor") is capable of screwing up packaged
modules.

But I totally agree with the point - there is no guarantee that you would
be able to install a working version.

The reason I quibble the detail is that as I can't see what could go wrong
with the code itself (distinct from attempting the installation of the code)
and hence how to make the code itself more robust.

> 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.

That tyranny of choice also makes it very hard to find a single replacement.

> 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.

Yes. Which means that its current "need" for FCGI needs to be resolved
first.

Nicholas Clark

Nicholas Clark <nick@ccl4.org> writes:

>> As a CPAN module, you'll have to install it yourself, if you can, and
>> there's no guarantee it will work.
>
> I'm having trouble parsing the last "it". In that, if you can install it
> (the module), then I'm failing to envisage a situation where the code
> wouldn't work, as the code is identical.

It is -- now. But currently CGI.pm is part of perl, in synch, and
maintained together. If removed from the core, there's no guarantee that
CPAN versions of CGI.pm will work with this or newer perls.

-- Johan

* Christian Walde <walde.christian@gmail.com> [2013-05-24T05:56:48]
> On Fri, 24 May 2013 11:06:49 +0200, Alexandr Ciornii
> <alexchorny@gmail.com> wrote:
> >It would not be easy to do on web hosting which does not has
> >possibility of installing modules from CPAN. Also currently CGI.pm
> >requires FCGI which requires compiler which frequently is not
> >installed.
>
> I ask for this to be considered a blocker for uncoring CGI.pm. As
> much as i dislike it, many people are in environments where no
> compiler is available (welcome to corporate policy) and will have a
> very rude awakening many years in the future when their Perl is
> upgraded.

Thank you for bringing this to my attention. I have filed:

https://rt.cpan.org/Ticket/Display.html?id=85595

--
rjbs

On Fri, May 24, 2013 at 2:25 AM, Nicholas Clark <nick@ccl4.org> wrote:

>> It would not be easy to do on web hosting which does not has
>> possibility of installing modules from CPAN. Also currently CGI.pm
>> requires FCGI which requires compiler which frequently is not
>> installed.
>
> Yes, this is strange. The core merrily ships CGI.pm without FCGI, yet the
> CPAN version of CGI.pm insists that FCGI is a hard dependency. Clearly the
> dependency can't be a hard dependency, else the version shipped by the core
> wouldn't work.
>
> And, as you say, the dependency makes it hard to install (or upgrade) CGI.pm
> on a system without a compiler.
>
> What stops CGI.pm making FCGI optional? Or splitting out the FCGI support
> into a separate distribution?

+1 to get FCGI dependency out of CGI.pm and make a separate
distribution. My experience tells Mark Stosberg, current maintainer of
CGI.pm, is likely in favor of splitting out these kinds of
dependencies out of distributions.


--
Tatsuhiko Miyagawa

On Fri, May 24, 2013 at 7:53 AM, Johan Vromans <jvromans@squirrel.nl> wrote:

> demerphq <demerphq@gmail.com> writes:
>
> >> It would not be easy to do on web hosting which does not has
> >> possibility of installing modules from CPAN. Also currently CGI.pm
> >> requires FCGI which requires compiler which frequently is not
> >> installed.
> >
> > Maybe the consequence of this would be that hosting services start
> > adopting a more progressive approach to this subject.
>
> That would have been so several years ago. I don't think it works like
> that nowadays.
>
> Hosting provider: Here's your system. Good luck.
> Client: Hey, I need perl!
> Hosting provider: Perl's on the system.
> Client: But I need to install modules to get my web application going.

Hosting provider: Can't do. Please use php / ruby / ... instead.
>

huh? It's not like you need special permissions to install modules!

On Sat, May 25, 2013 at 12:42 AM, Eric Brine <ikegami@adaelis.com> wrote:
> huh? It's not like you need special permissions to install modules!

I think the point was that the CPAN CGI distribution depends on FCGI,
which requires a complier, which not all hosting providers offer.
Hosting providers may not provide shell access, either, which makes
module installation harder.

But (a) we're going to get the FCGI dependency fixed, I think, and (b)
I don't think core Perl decisions should be based on meeting the needs
of people on lobotomized hosting plans.

David



--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

On Sat, May 25, 2013 at 6:42 AM, Eric Brine <ikegami@adaelis.com> wrote:
> huh? It's not like you need special permissions to install modules!

Now if only someone would make a web based CPAN client (that would
also install local::lib if required). Actually bootstrapping that
would be the only reason I'd ever use CGI.pm…

Leon

On Fri, May 24, 2013, at 5:53, Johan Vromans wrote:
> demerphq <demerphq@gmail.com> writes:
>
> >> It would not be easy to do on web hosting which does not has
> >> possibility of installing modules from CPAN. Also currently CGI.pm
> >> requires FCGI which requires compiler which frequently is not
> >> installed.
> >
> > Maybe the consequence of this would be that hosting services start
> > adopting a more progressive approach to this subject.
>
> That would have been so several years ago. I don't think it works like
> that nowadays.
>
> Hosting provider: Here's your system. Good luck.
> Client: Hey, I need perl!
> Hosting provider: Perl's on the system.
> Client: But I need to install modules to get my web application going.
> Hosting provider: Can't do. Please use php / ruby / ... instead.

I have to admit that I work for a hosting provider (a large one,
however,) and I know they're not like that. I remember talking to one of
our tech support agents who helped a customer install Catalyst, for
example.

--Curtis
--
Curtis Jewell
csjewell@cpan.org http://csjewell.dreamwidth.org/
perl@csjewell.fastmail.us http://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas: http://strawberryperl.com/beta/

On Sat, May 25, 2013 at 03:17:10PM -0600, Curtis Jewell wrote:

> > Hosting provider: Here's your system. Good luck.
> > Client: Hey, I need perl!
> > Hosting provider: Perl's on the system.
> > Client: But I need to install modules to get my web application going.
> > Hosting provider: Can't do. Please use php / ruby / ... instead.
>
> I have to admit that I work for a hosting provider (a large one,
> however,) and I know they're not like that. I remember talking to one of
> our tech support agents who helped a customer install Catalyst, for
> example.

I don't think it will be that big of an issue. Linux distros with
perl-5.18 are going to make a perl-CGI package, and all the hosting
provider has to do is add that to their list.

* Alexandr Ciornii <alexchorny@gmail.com> [2013-05-24 11:10]:
> It would not be easy to do on web hosting which does not has
> possibility of installing modules from CPAN.

* Johan Vromans <jvromans@squirrel.nl> [2013-05-24 14:05]:
> 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.
>
> As a CPAN module, you'll have to install it yourself, if you can, and
> there's no guarantee it will work.

Sirs, please, if I can beg your pardon, may I point you collectively in
the direction of App::FatPacker, if it’s no trouble.

On second thought, I also want to argue this point:

* Johan Vromans <jvromans@squirrel.nl> [2013-05-24 14:05]:
> 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.

If you want something quick and simple, why are you starting with CGI in
the first place? Maybe because you knew of it already, but then finding
CGI.pm among the hundreds of hits won’t be an issue. But if you didn’t
know of it already, where did you get the idea to look into CGI in 2013?
Not from any recent “web dev 101” intro.

> 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.

Come again? How does “ship CGI.pm in core” equate to “make it easy to
get started with simple web applications”? Who should *ever* be writing
new code against CGI.pm?

In terms of merit? No one.

Only one final reason to target CGI.pm in new code remains: that it has
always shipped with core. And making use of that advantage comes at high
cost for the code you write.

If improving the ease of getting started with web dev is your priority,
then your argument would really have to be about coring Plack (on which
I’d be -0) – even if you intend to deploy as a CGI.

The ones who are actually better served by keeping CGI.pm are those who
deploy existing CGI applications – not writers of new web applications.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Aristotle Pagaltzis <pagaltzis@gmx.de> writes:

> ... where did you get the idea to look into CGI in 2013?
> Not from any recent “web dev 101” intro.

True, my generation grew up with CGI. As a matter of fact, I co-authored
one of the very first books on using Perl on the web in 1995.

So apparently your main point against CGI.pm is that the ancient
knowledge of the CGI protocol is lost?

If I'd want a trivial web app that shows me yesterday's SinFest comic,
I'd use CGI.pm and 10-20 lines of Perl code. It would work on every web
host that has Perl. What would be your approach?

-- Johan
Never too old to learn something new

On Sun, May 26, 2013 at 3:21 PM, Johan Vromans <jvromans@squirrel.nl> wrote:
> If I'd want a trivial web app that shows me yesterday's SinFest comic,
> I'd use CGI.pm and 10-20 lines of Perl code. It would work on every web
> host that has Perl. What would be your approach?

I would assume that "web 101 with Perl" would show a way to do it that
might be more than you need for a trivial app, but that scales into a
"real" app when called for.

Analogy: for a trivial object oriented program, I'll just use bless
and write my own accessors. But for teaching "how to write OO apps in
perl", I'd use Moose or Moo.

David


--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

On 26/05/2013 23:37, David Golden wrote:
> On Sun, May 26, 2013 at 3:21 PM, Johan Vromans <jvromans@squirrel.nl> wrote:

>> If I'd want a trivial web app that shows me yesterday's SinFest comic,
>> I'd use CGI.pm and 10-20 lines of Perl code. It would work on every web
>> host that has Perl. What would be your approach?
>
> I would assume that "web 101 with Perl" would show a way to do it that
> might be more than you need for a trivial app, but that scales into a
> "real" app when called for.
>
> Analogy: for a trivial object oriented program, I'll just use bless
> and write my own accessors. But for teaching "how to write OO apps in
> perl", I'd use Moose or Moo.

bless is the new CGI

--
Ruud

On Saturday May 25 2013 3:17:10 PM Curtis Jewell wrote:
> > Hosting provider: Here's your system. Good luck.
> > Client: Hey, I need perl!
> > Hosting provider: Perl's on the system.
> > Client: But I need to install modules to get my web application going.
> > Hosting provider: Can't do. Please use php / ruby / ... instead.
>
> I have to admit that I work for a hosting provider (a large one,
> however,) and I know they're not like that. I remember talking to one of
> our tech support agents who helped a customer install Catalyst, for
> example.

One previous web host I've had the misfortune of dealing with made it
extremely annoying to install modules (no shell access - worked around via a
cron job entry that I'd put in, let it run the install, and then I'd take it
back out of cron, I'm sure there are other workarounds available, too, but
this one didn't have me worrying about security since I was still inside the
webhost's panels).

And then they put gcc into a special user group, and I could no longer compile
anything.

The fact I had to even request access was annoying.

I don't think all web hosts are necessarily enlightened to developers' usage.

However, I've since switched, and am much happier now with shell access :)

That all said, my points are:

1) Not all web hosts are good ones.
2) I'm not sure we can keep the bad ones from being bad ones, so don't go too
crazy trying to help them from shooting their customers in the foot.

Darin McBride <dmcbride@cpan.org> writes:

> 1) Not all web hosts are good ones.
> 2) I'm not sure we can keep the bad ones from being bad ones, so don't go too
> crazy trying to help them from shooting their customers in the foot.

My points, exactly.

-- Johan

On Mon, May 27, 2013 at 4:21 AM, Johan Vromans <jvromans@squirrel.nl> wrote:

> If I'd want a trivial web app that shows me yesterday's SinFest comic,
> I'd use CGI.pm and 10-20 lines of Perl code. It would work on every web
> host that has Perl.

I'm pretty sure that script would involve the code to fetch HTML page
from SinFest and parse it. It requires LWP (or some other HTTP
library) which is not in core. You can instead use wget, curl,
HTTP::Tiny for sure - none of them are guaranteed to be available on
"every web host that has Perl" anyway.

Instead, if you want to ensure your script works even when CGI.pm is
not shipped with Perl, or with an even worse provider that strips
modules like CGI.pm from perl core library (I know a few):

> cpanm -l vendor --reinstall CGI

and add 'use lib "./vendor/lib/perl5"' to your script, then upload the
whole code and vendor directory, and you're done. You don't even need
a shell access or local::lib integration.

Adding LWP or HTTP::Tiny to that is also as trivial, so long as XS
module is not involved [1].

(Fatpacker is an alternative to this to do the same thing, but only
required if you need a single file executable)

[1] At this moment, installing CGI.pm requires FCGI which needs XS
binary to be built. As you can see on the thread I believe this will
be resolved soon so that it's not the case.

--
Tatsuhiko Miyagawa

> From: Tatsuhiko Miyagawa [mailto:miyagawa@gmail.com]

> (Fatpacker is an alternative to this to do the same thing, but only
> required if you need a single file executable)

thanks for letting know, its useful :)

>
> [1] At this moment, installing CGI.pm requires FCGI which needs XS
> binary to be built. As you can see on the thread I believe this will
> be resolved soon so that it's not the case.

FWIW CGI.pm is a single-file module, so it could be even slurped into the
cgi script, (so 'fatpacker' even not needed) or just copied into current dir
and used from there.

but - more to the point - IMO number of obsoleted modules should be
stripped from the core, not only CGI, nowadays these mostly are - DB
modules such as SDBM_File AnyDBM_File etc

regards,
Vadim.

On Tue, 28 May 2013 06:12:07 +0000, "Konovalov, Vadim (Vadim)** CTR **"
<vadim.konovalov@alcatel-lucent.com> wrote:

> > From: Tatsuhiko Miyagawa [mailto:miyagawa@gmail.com]
>
> > (Fatpacker is an alternative to this to do the same thing, but only
> > required if you need a single file executable)
>
> thanks for letting know, its useful :)
>
> >
> > [1] At this moment, installing CGI.pm requires FCGI which needs XS
> > binary to be built. As you can see on the thread I believe this will
> > be resolved soon so that it's not the case.
>
> FWIW CGI.pm is a single-file module, so it could be even slurped into the
> cgi script, (so 'fatpacker' even not needed) or just copied into current dir
> and used from there.
>
> but - more to the point - IMO number of obsoleted modules should be
> stripped from the core, not only CGI, nowadays these mostly are - DB
> modules such as SDBM_File AnyDBM_File etc

I would agree with the sentiment that SDBM_File and ODBM_File are not
really state-of-the-art backends for tie-ing anymore, but they are
really different from CGI in the sense that the detection for the
libraries and include files is already well supported in Configure and
hints, and thus takes a huge burden of maintainers that might want to
keep these updated separately on CPAN. Both are not only XS, but also
need (a lot) of stuff on the system. Some systems are known for example
to have fake interfaces to these mimicked by similar interfaces.

> regards,
> Vadim.

--
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/

On Tue, May 28, 2013 at 08:20:31AM +0200, H.Merijn Brand wrote:
> On Tue, 28 May 2013 06:12:07 +0000, "Konovalov, Vadim (Vadim)** CTR **"
> <vadim.konovalov@alcatel-lucent.com> wrote:

> > but - more to the point - IMO number of obsoleted modules should be
> > stripped from the core, not only CGI, nowadays these mostly are - DB
> > modules such as SDBM_File AnyDBM_File etc
>
> I would agree with the sentiment that SDBM_File and ODBM_File are not
> really state-of-the-art backends for tie-ing anymore, but they are
> really different from CGI in the sense that the detection for the
> libraries and include files is already well supported in Configure and
> hints, and thus takes a huge burden of maintainers that might want to
> keep these updated separately on CPAN. Both are not only XS, but also
> need (a lot) of stuff on the system. Some systems are known for example
> to have fake interfaces to these mimicked by similar interfaces.

I believe in the past it's been mentioned that GDBM_File, NDBM_File and
ODBM_File *not* being dual life is a pain because you can't build them
after you've already installed perl. Which can matter, if you installed
perl before you realised that you didn't have the development headers in
place (or your upstream binary provider did not).

SDBM_File does not have this problem as it has no external dependencies.
AnyDBM_file *needs* to stay in the core as it's part of the implementation
of dbmopen.

In relation to this, previously I'd said that it would be fine if someone
wanted to make GDBM_File, NDBM_File and ODBM_File dual life.

No-one volunteered.


This is always the case. Talk is cheap, and there is a lot of it.

Nicholas Clark

On Fri, May 24, 2013 at 03:07:34PM +0200, Johan Vromans wrote:
> It is -- now. But currently CGI.pm is part of perl, in synch, and
> maintained together. If removed from the core, there's no guarantee that
> CPAN versions of CGI.pm will work with this or newer perls.

There's a higher chance if you volunteer to be co-maint for it :)