Re: Minimum modules for Production?

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 15:25]:
> I believe I said "in Perl6 modules" not "in the language core"
> as you imply

My apologies; I misremembered the argument, and the PHP example
you gave only happened to reinforce my misconception.

I agree then; having clients for a few network protocols in the
core distro seems very important to me as well. (Since we’re on
that, I would also say that having some kind of very lightweight
XML writer, at minimum, is a necessity nowadays.)

> As for writing bad code that is therefore easy to exploit, I
> wasn't suggesting that either. I personally advise taint be
> turned on for ALL web code, but that's another thread I
> believe, and this one has already started to unravel. :-)

Well yes, failure to validate input is obviously the programmer’s
fault. However, the more implicit magic an API provides, the more
dangerous it is, and the more care is necessary when validating
data to be given to it. This is why IO::All gives me the willies,
f.ex., even as I understand and agree with Ingy’s motivations at
large. I haven’t used two-argument `open` in Perl either since
the three-argument form became available. Go look at what Dan
Bernstein says about APIs…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Minimum modules for Production?

[Graham Barr]

On Jun 1, 2006, at 11:37 AM, Josh Wilmes wrote:



At 12:00 on 06/01/2006 BST, David Cantrell <[EMAIL PROTECTED]>  
wrote:



Basic I/O is talking to filehandles and nyetwork sockets.  Anything
above the UDP / TCP level should not, IMO, be included.


I agree.


I'd respectfully disagree.  Just like text isn't just ascii any more,
content isn't just on local filesystems.  HTTP has become pretty much
"basic".


If you use it. When my work involved a lot of internet related stuff  
I would have agreed. But with the work I do now my use of HTTP with  
perl is at 0%.


Everyone has a bias in their own thoughts of what the minimum is.  
"basic" should only be the common subset of them.


Graham.

Re: Minimum modules for Production?

[Michael Mathews]

On 02/06/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 12:10]:
> I would also point to PHP's fread() (and friends) functions,
> which take "filenames" in the form of "C:\\blah" or
> "http://foo.com/blah"; and behaves the same.

Yes, which means that any un- (or badly) sanitised user input has
the potential to make a program fetch data from a remote server,
which is particularly dumb when you consider that `require`
offers the same misfeature. Makes exploits so much easier.

No, HTTP is not like opening local files and should not be
treated as such. The failure modes also differ entirely.

The right place to abstract this, if you want to, is at the
networking layer, which could treat local files as a special form
of remote ones, which can be done simply by accepting `file://`
URIs in addition to `http://` and `ftp://`. This way around works
much better for a range of reasons. (I'm too lazy to go into them
right now but will if you ask.)

That doesn't belong in the language core, though.


That last point is very good argument, but oddly isn't to do with
anything I said (or that I've read in this thread for that matter). I
believe I said "in Perl6 modules" not "in the language core" as you
imply, and I read Josh's post to be about a so-called "core"
*distribution* with network *modules* included, but again, not about
the language core.

The example I gave from PHP was just one example of how "they" do it.
We can abstract it in whatever layer we want, but I think the point
was that accessing files in an increasingly networked world requires
network-smart modules, so some of those should be on the short list
for early porting, at least that was what I was trying to say.

As for writing bad code that is therefore easy to exploit, I wasn't
suggesting that either. I personally advise taint be turned on for ALL
web code, but that's another thread I believe, and this one has
already started to unravel. :-)

--michael

Re: Minimum modules for Production?

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 12:10]:
> I would also point to PHP's fread() (and friends) functions,
> which take "filenames" in the form of "C:\\blah" or
> "http://foo.com/blah"; and behaves the same.

Yes, which means that any un- (or badly) sanitised user input has
the potential to make a program fetch data from a remote server,
which is particularly dumb when you consider that `require`
offers the same misfeature. Makes exploits so much easier.

No, HTTP is not like opening local files and should not be
treated as such. The failure modes also differ entirely.

The right place to abstract this, if you want to, is at the
networking layer, which could treat local files as a special form
of remote ones, which can be done simply by accepting `file://`
URIs in addition to `http://` and `ftp://`. This way around works
much better for a range of reasons. (I’m too lazy to go into them
right now but will if you ask.)

That doesn’t belong in the language core, though.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

Re: Minimum modules for Production?

[Fagyal Csongor]

Hi,


However, as has been pointed out regarding MS Word, most users only
use a very tiny subset of its functionality.  The problem is that the 
users

are using different subsets.  I've done huge amounts of HTML parsing and
can't recall having used GDBM_File.



It all comes to *different* subsets 


I think if we leave out but one module from CPAN, someone will miss it.
However, 98% of all Perl users will be happy with 2% of all (current 
Perl5) CPAN modules.



I wrote a lot of Perl for Unix, VMS and Windows system management,
text files processing and connectivity to databases (Oracle and LDAP).
I never used an HTML parser and only used LWP once.

So for me a stripped down version of Perl with reasonable I/O
capabilities (print, open, close, ) would be just enough and i can
settle for an easy-to-install connectivity bundle.

Then again, i only represent myself.



Some use Perl for biometric, some for converting SVG to PDF, some for 
creating desktop applications. But that is not typical. System 
administration and "web/net programming" covers most of the tasks most 
Perl users use Perl for. So my list would be something like:


- basic protocols, say UDP and TCP (so that you have something to build on)
- a little more higher level protocols, say HTTP / HTTPS, POP3, IMAP, 
SMTP (you want to *send mail*, don't you?)

- something LWP-like, so you can handle GET/POST and Cookies
- something CGI-like, so that you can url_encode(), 
$cgi->param("submit") and such

- Digest::* Who can live without md5_hex() ?
- Crypt::* DES, 3DES, Blowfish, SSL...
- Serialize: thaw/freeze (yep, something like Storable)
- something like Data::Dumper (to see what you are doing)
- a template handler (like TT2 - preferably TT3 or TT6 :))
- XML parsing/generation (we must be serious...)
- HTML parsing, I second that (so that you can WWW::Mechanize and 
HTML::FillInForm and so on...)

- command line argument parsing (LongOpt or whatsthename)
- DBI
- MIME (you want to send mail with attachments, too :))
- some kind of image manipulation, probably using an external library 
(to populate your TGPs :))) - ImageMagick comes to the mind


And for the sake of my open source Perl5 framework, so that I can start 
thinking about the Perl6 version :), these would make *me* happy :

- FastCGI
- Config::General
- Cache::*





- Fagzal

Re: Minimum modules for Production?

[Amir E. Aharoni]

However, as has been pointed out regarding MS Word, most users only
use a very tiny subset of its functionality.  The problem is that the users
are using different subsets.  I've done huge amounts of HTML parsing and
can't recall having used GDBM_File.


It all comes to *different* subsets 

I wrote a lot of Perl for Unix, VMS and Windows system management,
text files processing and connectivity to databases (Oracle and LDAP).
I never used an HTML parser and only used LWP once.

So for me a stripped down version of Perl with reasonable I/O
capabilities (print, open, close, ) would be just enough and i can
settle for an easy-to-install connectivity bundle.

Then again, i only represent myself.

--
Amir Elisha Aharoni, http://aharoni.blogspot.com/
"We're living in pieces,
I want to live in peace." - Thurston Moore
__
Please avoid sending me Word or PowerPoint attachments
http://www.gnu.org/philosophy/no-word-attachments.html

Re: Minimum modules for Production?

[Michael Mathews]

If LWP isn't on the list I give it a vote.

--michael

Re: Minimum modules for Production?

[Ovid]

- Original Message 
> From: David Cantrell <[EMAIL PROTECTED]>
>
> Too many people have said "it'll be over by christmas" for me to have
> any confidence in such prognostications, but ...

I can't say I blame you.  I'm just going by my gut, what I've seen before and 
what some birds have sung in my ear.  My opinion on this matter, though, is 
strictly my opinion and is in no way official.

> I doubt a HTML parser is that important.  Something like Storable and
> GDBM_File are though.


When Andy mentioned the Phalanx project, I had the same reaction to some of the 
modules in that project.  However, as has been pointed out regarding MS Word, 
most users only use a very tiny subset of its functionality.  The problem is 
that the users are using different subsets.  I've done huge amounts of HTML 
parsing and can't recall having used GDBM_File.  Perl6 without a robust HTML 
parser would be quite limited for me, though I'm sure one will be ready soon.

Cheers,
Ovid

Re: Minimum modules for Production?

[David Cantrell]

On Tue, May 30, 2006 at 07:50:35PM +0200, Amir E. Aharoni wrote:

> In that case only the compiler and the most basic I/O functionality
> needs to be in and i agree that it's not a bad idea.
> 
> There should be easy-to-install bundles of modules though -
> connectivity bundle, DB bundle, webserver bundle, algorithms bundle,
> Unix sysadmin bundle, Win32 bundle, Math bundle etc. Stuff like
> DateTime can go to some kind of a Utils bundle.

Thankfully, that's really easy to do with CPAN.  See, eg, Bundle::Math
or Bundle::Perl6.

-- 
David Cantrell | London Perl Mongers Deputy Chief Heretic

  While researching this email, I was forced to carry out some
  investigative work which unfortunately involved a bucket of
  puppies and a belt sander
-- after JoeB, in the Monastery

RE: Minimum modules for Production?

[Conrad Schneiker]

> From: Ovid [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 29, 2006 5:53 PM
[...] 
> Since it looks like we're really going to have Perl6 within a year
> or so, what are the "must have" modules folks will want before they
> can consider using Perl6 in production? 

Interesting that there was no mention of using Perl 5 modules in this
thread (unless I missed it). Will that be a feasible and practical
approach to getting off the ground? Or will it take too much added
interfacing effort? Or is this sort of feature going to follow some
time after the initial release?

As far as distributions, I'd like to see (1) a maximally portable and
minimalist "Swiss Army knife" version to get Perl 6 in as many doors
as possible, and (2) a "Wizard's workshop" version that was something
of a (P5ish+ scale) "best practices" + "cookbook" + "power tools"
version. 

Specialist distributions could then use either of these as their point
of departure to build on. (2) would be typically be more oriented to
the "big 3" platforms. While I suppose it could be treated as a
super-bundle, it would be probably be generally advantageous if it
were a standard distribution of the sort that (for example)
ActiveState would provide. 

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)

Re: Minimum modules for Production?

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2006-05-30 02:55]:
>   An HTML parser

That should wait till Grammars and Rules are ready to fly, I
think, after which (I assume) it should get implemented very
quickly.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Minimum modules for Production?

[David Cantrell]

On Mon, May 29, 2006 at 05:53:20PM -0700, Ovid wrote:
> Since it looks like we're really going to have Perl6 within a year or so, 
> what are the "must have" modules folks will want before they can consider 
> using Perl6 in production? Right off the bat, I see a need for the following:

Too many people have said "it'll be over by christmas" for me to have
any confidence in such prognostications, but ...

>   DBI (I hear Tim Bunce is looking at this)
>   Template Toolkit (I've heard rumors that  Andy Wardley is considering this, 
> but I'm not sure)
>   DateTime
>   CGI
>   Some object-relational mapper
>   mod_perl6 or some equivalent
>   An HTML parser
>   Various testing modules

I doubt a HTML parser is that important.  Something like Storable and
GDBM_File are though.

-- 
David Cantrell | random organic glop and a metric fuckton of electricity

I hate baby seals.  They get asked to all the best clubs.

Re: Minimum modules for Production?

[Rutger Vos]

I believe the name is supposed to be 'Perl on Planks'.

Michael Mathews wrote:

On 30/05/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

 If we have to pander to the clueless in order to
make life easier for those in the trenches, I suggest that a
Perl 6 distribution that includes as many modules as feasible be
maintained as a strictly separate project. But the P5ish emphasis
on core modules has to go.


I happen to agree with Aristotle about keeping the core skinny, and
giving people the option to make their own installs fat in whatever
way they prefer. Seems like Ruby can have Rails, and they're
comfortably two different things. Perl6 can have it's own specialised
"framework/s", maybe it will be called it Perl6 on Pajamas, or
whatever, but it can be a completely separate thing. Not an issue.

If any company doesn't want to use open, community tried and reviewed
source code, they are more than welcome to roll their own, but trust
me, it ain't going to automatically become more secure just because no
one outside the company has seen it!

--michael





--

Rutger Vos, PhD. candidate
Department of Biological Sciences
Simon Fraser University
 University Drive
Burnaby, BC, V5A1S6
Phone: 604-291-5625 
Fax: 604-291-3496

Personal site: http://www.sfu.ca/~rvosa
FAB* lab: http://www.sfu.ca/~fabstar
Bio::Phylo: http://search.cpan.org/~rvosa/Bio-Phylo/

Re: Minimum modules for Production?

[Amir E. Aharoni]

On 5/30/06, Michael Mathews <[EMAIL PROTECTED]> wrote:
...

I suggest that a
> Perl 6 distribution that includes as many modules as feasible be
> maintained as a strictly separate project. But the P5ish emphasis
> on core modules has to go.


In that case only the compiler and the most basic I/O functionality
needs to be in and i agree that it's not a bad idea.

There should be easy-to-install bundles of modules though -
connectivity bundle, DB bundle, webserver bundle, algorithms bundle,
Unix sysadmin bundle, Win32 bundle, Math bundle etc. Stuff like
DateTime can go to some kind of a Utils bundle.


I happen to agree with Aristotle about keeping the core skinny, and
giving people the option to make their own installs fat in whatever
way they prefer. Seems like Ruby can have Rails, and they're
comfortably two different things.


I haven't tried Rails, but i just hope that if such a killer app
emerges for Perl6, it won't be like Zope or BitTorrent which bundle
their tailored Python interpreter and libs in the default
installation.

--
Amir Elisha Aharoni, http://aharoni.blogspot.com/
"We're living in pieces,
I want to live in peace." - Thurston Moore
__
Please avoid sending me Word or PowerPoint attachments
http://www.gnu.org/philosophy/no-word-attachments.html

Re: Minimum modules for Production?

[Michael Mathews]

On 30/05/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

 If we have to pander to the clueless in order to
make life easier for those in the trenches, I suggest that a
Perl 6 distribution that includes as many modules as feasible be
maintained as a strictly separate project. But the P5ish emphasis
on core modules has to go.


I happen to agree with Aristotle about keeping the core skinny, and
giving people the option to make their own installs fat in whatever
way they prefer. Seems like Ruby can have Rails, and they're
comfortably two different things. Perl6 can have it's own specialised
"framework/s", maybe it will be called it Perl6 on Pajamas, or
whatever, but it can be a completely separate thing. Not an issue.

If any company doesn't want to use open, community tried and reviewed
source code, they are more than welcome to roll their own, but trust
me, it ain't going to automatically become more secure just because no
one outside the company has seen it!

--michael

Re: Minimum modules for Production?

[A. Pagaltzis]

* Amir E. Aharoni <[EMAIL PROTECTED]> [2006-05-30 10:00]:
> My previous workplace was very anal about installing software
> from the web - they hardly let me install ActivePerl - and i'm
> sure that it's not the only one.

Yes, the adminstration and networking policies at many companies
are broken; unbelievably so, in some cases. I don’t believe that
makes it a bright idea to hang the “which modules do we put in
core” albatross that caused so much grief for p5p around Perl 6’s
neck yet again. If we have to pander to the clueless in order to
make life easier for those in the trenches, I suggest that a
Perl 6 distribution that includes as many modules as feasible be
maintained as a strictly separate project. But the P5ish emphasis
on core modules has to go.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Minimum modules for Production?

[Michael Mathews]

On 30/05/06, Amir E. Aharoni <[EMAIL PROTECTED]> wrote:

BEEP-BEEP - for some reason, every time i hit "Reply" my reply is sent
to the poster and not to the list. Is the bug in my mailer (GMail), my
head, or the list server?


I had the same problem with GMail, or at least how GMail tries to be
"helpful" by rearranging how the reply addresses are handled. You must
press "reply all" then rearrage the To: and CC: fileds, as I am about
to do now. Grrr

--michael

Re: Minimum modules for Production?

[Michael Mathews]

On 30/05/06, Ovid <[EMAIL PROTECTED]> wrote:

Since it looks like we're really going to have Perl6 within a year or so, what are the 
"must have" modules folks will want before they can consider using Perl6 in 
production?


I vote for: 1) Unit testing, like Test::More; and 2) XML::Parser;

--michael

Re: Minimum modules for Production?

[Andy Lester]

On May 29, 2006, at 7:53 PM, Ovid wrote:

Since it looks like we're really going to have Perl6 within a year  
or so, what are the "must have" modules folks will want before they  
can consider using Perl6 in production? Right off the bat, I see a  
need for the following:


  DBI (I hear Tim Bunce is looking at this)
  Template Toolkit (I've heard rumors that  Andy Wardley is  
considering this, but I'm not sure)

  DateTime
  CGI
  Some object-relational mapper
  mod_perl6 or some equivalent
  An HTML parser
  Various testing modules


LWP.

Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance