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:[EMAIL PROTECTED]]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
>
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
