Re: [RFC] Starting 5.3

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. -- Wbr, Antony Dovgal