Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29309 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52859 invoked by uid 1010); 8 May 2007 08:36:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 52843 invoked from network); 8 May 2007 08:36:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 May 2007 08:36:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain php.net from 85.214.94.56 cause and error) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Received: from [85.214.94.56] ([85.214.94.56:36997] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DC/C2-10930-B7630464 for ; Tue, 08 May 2007 04:36:12 -0400 Received: from baumbart.mbo (dslb-084-063-031-131.pools.arcor-ip.net [84.63.31.131]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id 6DBFB1B3629 for ; Tue, 8 May 2007 10:36:08 +0200 (CEST) Date: Tue, 8 May 2007 10:36:16 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1376921277.20070508103616@marcus-boerger.de> To: internals@lists.php.net In-Reply-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Starting 5.3 From: helly@php.net (Marcus Boerger) Hello internals, Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote: > On 5/8/07, Derick Rethans wrote: >> On Mon, 7 May 2007, Stanislav Malyshev wrote: >> >> > > We will need it: >> > > - by the time of PHP 6 >> > >> > I think this problem should be fixed not by killing PEAR and converting it to >> > PHP extensions but by fixing PHP 6 and enabling PEAR to work. >> >> Let me agree with Greg here. We can not go back to the PHP 4.x way of >> bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 >> uses the phar, which works brilliantly. So the fix here is to make >> something *like* phar work with PHP 6 as well. If it was to be based on >> streams (which I think it can only be), then we *need* some way of >> marking this new user stream as being local in order for require and >> include to work on those. Making a hack in PHP to allow "phar://" >> streams to work is a bad idea, a C-extension can easily work here. > 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. 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? In the past we have bundeled even stuff that has not been stable or in a mature state. And I have not seen a single reason against it. The only one close so far was that PHARs cannot be handled with your favorite Winzip or whatever you are using. Guess what, I have PHP installed and last time I checked PHP worked nearly perfectly. And last time I had to deal with JARs I did not have the slightest advantage of having it be a ZIP file. Just because in all those Java formats you have to provide specific files in a very specific format with very specific content. And this is the absolute opposite of the flexibility we aim for with Phar. 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? Best regards, Marcus