Mailing List Archive

1 2  View All
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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/
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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.
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
* 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.
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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/>
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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.
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
RE: RFC: Removing CGI.pm from the core distribution [ In reply to ]
> 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.
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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/
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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
Re: RFC: Removing CGI.pm from the core distribution [ In reply to ]
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 :)

1 2  View All