Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29270
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 66.79.163.178 cause and error)
Message-ID: <463F6E41.1010202@chiaraquartet.net>
Date: Mon, 07 May 2007 13:21:53 -0500
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>
CC: PHP internals <internals@lists.php.net>
References: <139872287.20070504170744@marcus-boerger.de> <736AED54-1272-4924-A07D-3166A1742A2F@prohost.org> <698DE66518E7CA45812BD18E807866CE2FEF72@us-ex1.zend.net> <463EDD0B.7080300@lsces.co.uk> <463F3724.1070703@chiaraquartet.net> <463F53B2.2030009@lsces.co.uk>
In-Reply-To: <463F53B2.2030009@lsces.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: greg@chiaraquartet.net (Gregory Beaver)

Lester Caine wrote:
> Gregory Beaver wrote:
>> Phar is not yet perfect, but is also not NEARLY as complex as PDO.
>> There is no comparison.
> 
> The 'comparison' was in the way these packages get added without proper
> investigation ;) Someone decides that THIS is how it will be done, and
> that is what happens :( and we have to live with the consequences.

Please, this is ridiculous, your response is completely out of
proportion to what is happening.  Marcus proposed the addition of phar
to core in 5.3, and is now asking for public comment.

> How would I use 'phar' with the four thousand files that make up
> bitweaver? I have had a quick look, but I don't yet see how I handle all
> the installation and management options for installing and updating
> packages that bitweaver has been designed to support. ADOdb and smarty
> provide the core libraries, and the liberty shell is built on those.
> Only those packages that are needed are download to the target system. I
> suspect we would have to build phar files for each package, but
> currently styles and themes can easily be managed via a few file
> changes, something that phar would seem to make a lot more difficult.
> Private tweaks to the libraries provide performance and operational
> improvements that would not be possible if ADOdb or smarty were supplied
> 'packed'. But without example phar libraries to look at and pull apart
> proper investigation is difficult - as people have already said.

phar is best for self-contained libraries or applications that do not
need to modify their source code.  Many applications (like phpmyadmin)
do configuration by modifying a source code file and then including it.
 This practice would require that the phar.read_only INI setting be off
in php.ini (it is on by default).

Also useful and not yet implemented would be to allow include_path to
have a phar:// archive, as many issues with "pharring" applications
would no longer exist.  Controversy doesn't even begin to describe the
reaction I expect from this suggestion, however.

Thanks,
Greg