Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Date: Mon, 28 Jan 2008 23:04:31 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE0133A231@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
Thread-Index: Achh09lO1MTdRvHSS4eo5oAKJ4hVNgAcOQDA
References: <479E1152.50301@chiaraquartet.net>
To: "Gregory Beaver" <greg@chiaraquartet.net>,
	"internals Mailing List" <internals@lists.php.net>,
	"Steph Fox" <steph@phparch.com>,
	"Marcus Boerger" <mail@marcus-boerger.de>
Subject: RE: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
From: andi@zend.com ("Andi Gutmans")

Hey Greg,
=09
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.
=09
Thanks!

Andi

> -----Original Message-----
> From: Gregory Beaver [mailto:greg@chiaraquartet.net]
> 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
>=20
> Hi all,
>=20
> 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:
>=20
> Criticisms:
>=20
>  * 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
>=20
> Current status of phar addresses most of these criticisms:
>=20
>  * 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.
>=20
> 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.
>=20
> 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)
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Thanks,
> Greg
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php