Hello Antony, it make it much harder as you would need to load PHP_Archive before you can do anything else with them. It would mean you cannot easily execute them unless they contain PHP_Archive themselves....
best regards marcus Tuesday, May 8, 2007, 11:39:32 AM, you wrote: > On 05/08/2007 01:17 PM, Marcus Boerger wrote: >>> 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. > Please correct me if I'm wrong: phars do work without PECL/phar, don't they? > Then why in hell do we need PECL/phar in the core? (except for that streams > problem) > Because it's faster than PHP_Archive? > I don't really care if PEAR install takes 5 seconds or 4 seconds, I can > wait one more second once in a month. > >>> 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. > The only tool required is autoconf (2.13 is recommended, other versions are > supported too). > All the other tools are required by PHP itself. You don't need to be an > experienced admin to > install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight > it.. > (Btw, Ilia recently proposed to create packages with pre-built configure, > so even the autoconf requirement would go). >> 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). > I'm not sure I understand what you're talking about. > We never provided debug binary builds and I see no reasons to do it. >> Andwewould have to decide on a sane pugable API. > Okay, let's do it. > We have a nice chance to break everything we can - it's PHP6 anyway =) > I'd really like to hear your thoughts on improving the API. > Want to make a separate thread? >> 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. > This IS the discussion board. >> So how is this ever going to happen? >> So infact if we like something we can either bundle it or have it die. > Ok, so let me summarize it: > to leave PECL/phar in PECL you need a new pluggable API, > and to create the API you need a discussion board, > but even having it you would not discuss the API because nobody respects > TODOs. > Did I miss something? >>>> 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. > PECL/json, PECL/zip and the others were/are stable too. > That doesn't mean there are no bugs we don't know of. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
