Hello Gregory,
My point of view is this action list:
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though technically I guess that 2a
is probably much faster to achive.
best regards
marcus
p.s.: I haven't done much in regards to Phar lately - and can only say that
you did an amazing not expect job. You turned Phar into something way
better than we ever thought of.
Monday, January 28, 2008, 6:30:58 PM, you 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.
> Thanks,
> Greg
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
