Re: Working Group Proposal

Well, the example you gave was about putting support for http, ftp, etc, etc
at the COMPILE level. That, imo, is too great of a distinction. Say your ISP
has a non-standard version of perl...you're stuck, and it sucks. Rather,
just take the pluggable modules approach...

The open keyword does nothing but delegate. When you pass it a filename, it
loads the 'open::filename' module, and passes it the parameters, which
proceed to open the file for reading in some standard stream format. If I
passed it 'http://', it would open the 'open::http' module which could just
have hooks into the LWP modules or something. With this approach, you can
just install/deinstall the modules, or extend open to include your own
proprietary format by creating a module. A palm-pilot could just not have
those modules exist, and perl could notify them nicely. The user could
choose to use up valuable memory on their networked palmpilot and add the
'open::http' module, or choose not to.

Of course, they'd be installed by default, and the only way to remove them
to create a microperl or minperl would be to remove them manually and
repackage perl or something. I don't think it should be something that's
optional when you install perl.

Just my $0.02,
Mike

----- Original Message -----
From: "horos" <[email protected]>
To: <[email protected]>
Sent: Monday, July 24, 2000 9:05 PM
Subject: Re: Working Group Proposal


> > >Include keyword 'open' in perl library? [y]
> > > Include support for 'http' in 'open' [y]
> > > Include support for 'ftp' in 'open' [y]
> > > Overload 'open' with other support (https, etc)? [n];
> >
> > Then you could say good-bye to portable Perl scripts.
> >
> > --tom
>
> well, not necessarily. Likelihood is that at first pretty much everybody
would
> use the same sets of defaults, hence executables would work the same
everwhere.
>
> But yes, ultimately there may be more than one group of defaults that make
> sense. If you want to embed perl on a palm-pilot, you really don't need
all the
> cruft that comes along with a full set of perl. Same goes if you are
embedding
> an interpreter into apache - lots of places aren't willing to pay the cost
> (in memory) to do this currently. And if you want to embed a perl
interpreter
> into an application, you may want to limit perl's ability to write to
disk.
> And so on.
>
> Monolithic is good, but only up to a certain point. But ultimately you run
into
> the MS problem, where they try to make 'one size fit all'. I don't want to
have
> only two sizes to perl: big and humongous. But that is the way it
currently
> stands...
>
> Ed