Hello Antony, Tuesday, May 8, 2007, 10:59:28 AM, you wrote:
> 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. It is not my main argument - not at all. My argument is that it is something that serves a need perfectly and makes the PHP_Archive stuff turned into a fast C extension. Including it would allow to make it a suggested sound and save deployment solution with a bunch of nice additional pros. >> 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. We have no means at all to support that. And even after years of having PECL I cannot see the slightest aim to solve the issue. All we have right now is to provide stuff that works for experienced admins. Experienced in compiling and automake tools. Before we can go in a all to PECL way of doing things we would need to reduce the number of completely incompatible builds (ZTS, debug, ZTS-debug, normal). Andwewould have to decide on a sane pugable API. One that does not change from version to version. Not even additions would be allowed. All would have to be done via callbacks. And eventually with struct versioning. But we do not even allow a TODO discussion board on php.net somewhere nor did we ever respect our own TODOs. So how is this ever going to happen? So infact if we like something we can either bundle it or have it die. >> 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? Phar is stable. All I said is that we won't do the same mistake again. Meaning that none of those arguemts speaks against Phar. If feel the need to misinterpret these arguments than i am sorry. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
