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