Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29311
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <46403BF0.8070409@zend.com>
Date: Tue, 08 May 2007 12:59:28 +0400
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC:  internals@lists.php.net
References: <139872287.20070504170744@marcus-boerger.de> <1348470081.20070504221609@marcus-boerger.de> <463EB3FD.4020009@zend.com> <1062653277.20070507092725@marcus-boerger.de> <463ED871.8080606@zend.com> <463F1B3A.3070703@pooteeweet.org> <463F74EA.7030704@zend.com> <1377895609.20070507211530@marcus-boerger.de> <463F8909.6000709@zend.com> <alpine.DEB.0.98.0705080822260.27587@kossu.ez.no> <fe05d1540705080113u2f675932i16de5ac6f997406f@mail.gmail.com> <1376921277.20070508103616@marcus-boerger.de>
In-Reply-To: <1376921277.20070508103616@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: antony@zend.com (Antony Dovgal)

On 05/08/2007 12:36 PM, Marcus Boerger wrote:
>> The point is to make local URL wrappers working, not only phar://.
>> Stanislav and Tony have a point, writing a custom extension to fix a
>> problem that we introduced is a bad idea and does not solve the
>> problem for anyone else but phar. If phar will be bundled or not does
>> not matter, this problem has to be solved anyway.
> 
> Right Pierre, as you said, this is a different thing that might have
> to be addressed anyway. However phar is a real life thing that needs
> to be working.
> 
> Besides, Phar is neither a custom extension - at least i do not see
> either Greg or me as PHP customers. Nor was Phar designed to solve
> that particular issue alone. It was designed to deliver a stable and
> fast implementation of PHP_Archive that can be bundled into PHP as
> a C extension.

But the main argument for including it that it's going to solve the newly created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.

> Guys what I don't understand is why some few people bicker around
> Phar so much, just because they have no private use for it? 

If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR.
I'm against including new PECL stuff in the core and I've repeated that several times already.
Things should go the other way round - from the core to PECL.

> In the past we have bundeled even stuff that has not been stable or in a
> mature state.

Well, THAT is a nice argument.
We've fucked it up in the past, let's do it again, huh?

> And I have not seen a single reason against it. 

I have not seen a single reason FOR it either.
The only half-valid reason is that phars will stop working in PHP6 because of the streams breakage.
But that's definitely the reason to fix streams, otherwise we'll have to include each & every extension using custom streams.

> Now adding Pecl/Zip was a clever idea as it allows an easy way to
> compress stuff on the fly for sites that offer downloads. However
> this is a) far far away from a mainstream problem and b) we should
> not eventhink of turning it into a JAR and hack around PHP all over.
> Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on
> the fly packing and Phar for deployment. And if some people want to
> execute phars directly, then why the hell make it hard for them or
> even disallow that?

-- 
Wbr, 
Antony Dovgal