On Mon, 28 Jan 2008 11:30:58 -0600, Gregory Beaver <[EMAIL PROTECTED]> wrote: > 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.
+1 for core inclusion. > > Thanks, > Greg > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php ///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
