horos <horos@earth.he.net> writes: > > >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. The size of the interpreter in Apache is trivial (and it's text so it's shared between processes) compared to the runtime memory costs. And runtime memory costs are usually due to lax programming and circular data structures that don't get on well with long lived processes. -- Piers