Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34967
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <479E1152.50301@chiaraquartet.net>
Date: Mon, 28 Jan 2008 11:30:58 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: internals Mailing List <internals@lists.php.net>, 
 Steph Fox <steph@phparch.com>,
 Marcus Boerger <mail@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: re-proposal of pecl/phar for inclusion in core
From: greg@chiaraquartet.net (Gregory Beaver)

Hi all,

I have been working hard on pecl/phar to address several issues raised
last May when it was first mentioned on the list, and would like to
summarize where phar stands today with regards to those criticisms:

Criticisms:

 * non-standard file format
 * limited introspection
 * no support for web-based applications
 * by default, phar archives require the phar extension to run
 * massive modification of php applications required to run them as a
phar archive
 * no caching of phar files in opcode caches
 * has write support in the extension

Current status of phar addresses most of these criticisms:

 * full read/write support for tar and zip file formats plus original
phar file format
 * introspection of phar-based archives is available via the "phar.phar"
command-line tool, and all standard tar/zip tools can introspect tar and
zip files
 * web-based phar archives has been completed, 1 line of code is needed
to enable the web front controller.  Concept proved by running
phpMyAdmin from its original tarball without code changes
 * default stub for phar-based archives allows standard PHP applications
to run from a phar archive without the phar extension being present.
 * interception of read-based file functions and include now allows most
php applications to run from a phar archive without any modification to
the original code
 * Gopal committed code to APC that allows caching of files from stream
wrappers
 * write support is disabled by default, and can only be enabled on the
system level, this has not changed.

phar is also the first PHP extension to provide full read/write support
of the tar file format on windows (libarchive supports this on unix)
phar implements zip support with native PHP code, enabling some features
not present in ext/zip such as opendir() stream support, bzip2
compression, file permissions stored in the zip archive, and greatly
improved efficiency on accessing just a few files within a large zip
archive.
phar also supports creating and running gzipped/bzipped tar or phar
archives without requiring decompression (this is done on the fly) at
the expense of the expected performance hit.

Phar has no required dependencies, and optional dependencies on spl,
zlib and bz2 (zlib+bz2 are obviously required for
compressing/decompressing with those formats, spl is only required for
fancy-pants stuff, the stream wrapper, web front controller, and other
major features do not require spl)

Development is still actively occurring on phar, to fix a few known
issues and increase code coverage in the unit tests.  The enhancements
above are in CVS in the soon-to-be-released phar 2.0.0.

If phar were in core, it would allow people distributing applications or
libraries to bundle unpacking code or installation code inside the
archive.  Applications could also be designed to run right out of the
phar archive for users to try them out or even for final installation
using the standard tar/zip file formats.  The phar file format has the
advantage of not requiring the phar extension in order to run.  The
tar/zip file formats have the advantage that if the phar extension is
not present a simple "unzip" command (or the equivalent for tar or for
windows) allows easy installation.

As such, I would like to ask for a second consideration of bundling phar
in core, as it has a huge potential for enhancing the distribution of
PHP applications.

Thanks,
Greg