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