RE: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

To continue a tangent... I don't like the idea of having the PEAR fetching/installation mechanism written in PHP (already some base code in PEAR to do this). It seems to me that it forces the user to download/build PHP and then download and rebuild PHP with any extensions that don't come in the base distribution. Instead it should be a binary that can be compiled before PHP is built, can download and configure any extensions requested and then build the resulting PHP binary. We can also build in a dependency mechanism where for example, someone chooses to install a PEAR module (be it PHP or C) and the required extensions would be downloaded as well. Just my $0.02 > -----Original Message----- > From: Ron Chmara [mailto:ron@Opus1.COM] > Sent: Wednesday, April 18, 2001 8:53 PM > To: Zeev Suraski > Cc: Frank M. Kromann; Sterling Hughes; Stig Sather Bakken; php-dev > mailinglist; Stig Sather Bakken > Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt > > > On Wednesday, April 18, 2001, at 05:33 PM, Zeev Suraski wrote: > > Guys, > > Over the years, there's always been a tendency to think > about things > > which are 10 steps ahead. It never worked, and I don't > think it would > > work here either. > > Well, a program spec (or idea) is certainly not the reality > of the final > codebase. > > But if we don't think a few steps ahead, (or at least know where it's > going), it's kind of hard to determine the steps to take here > and now, > or know where it's really going. I posted a list, and we > discovered that > PEAR already has dependancies on some /ext's, and (by > implication) that > if this continues in PEAR, eventually many of the minor ext's > may need > to be built to run PEAR.... in which case we may want to > leave the /ext > directory out of PEAR entirely. > > If something is going to be a possibility, it should probably be > considered before we build ourselves into a corner, and > implementing it > becomes impossible. > > > Whether or not we separate modules *at all* will greatly > depend on how > > good an implementation we end up having. > > Agreed 100%. > But that implementation, as it happens requires some feedback and > discussion, doesn't it? > > > How many of them we end up separating will also depend on > that. Let's > > just wait with those discussions until they're somehow > connected with > > reality. > > Counterpoint to this, of course, is that if we _would_ be doing this > with a PEAR scheme, we'd need to design that into PEAR, preferrably > without having to re-write PEAR from scratch to accomodate > this idea. :-) > > > -Ronabop > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: > php-list-admin@lists.php.net >