Hey Greg,
This looks very promising. Great to see that you took those feedbacks
and really attacked them leading to a huge improvement in phar (should I
say night and day :) I think you've really accomplished a lot in these
few months.
Are there any docs which describe the transparent front controller
configuration? I'd love to take a look and give it a spin.
Thanks!
Andi
> -----Original Message-----
> From: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 28, 2008 9:31 AM
> To: internals Mailing List; Steph Fox; Marcus Boerger
> Subject: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
