Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 85.214.94.56 cause and error)
Date: Wed, 9 May 2007 00:00:14 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1318260225.20070509000014@marcus-boerger.de>
To: Antony Dovgal <antony@zend.com>
CC: internals@lists.php.net
In-Reply-To: <46404554.5010304@zend.com>
References: <139872287.20070504170744@marcus-boerger.de> <1348470081.20070504221609@marcus-boerger.de> <463EB3FD.4020009@zend.com> <1062653277.20070507092725@marcus-boerger.de> <463ED871.8080606@zend.com> <463F1B3A.3070703@pooteeweet.org> <463F74EA.7030704@zend.com> <1377895609.20070507211530@marcus-boerger.de> <463F8909.6000709@zend.com> <alpine.DEB.0.98.0705080822260.27587@kossu.ez.no> <fe05d1540705080113u2f675932i16de5ac6f997406f@mail.gmail.com> <1376921277.20070508103616@marcus-boerger.de> <46403BF0.8070409@zend.com> <1551579245.20070508111713@marcus-boerger.de> <46404554.5010304@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: helly@php.net (Marcus Boerger)

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