Hello internals, Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote:
> On 5/8/07, Derick Rethans <[EMAIL PROTECTED]> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
