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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
