Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34969
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 28 Jan 2008 18:49:27 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1216062773.20080128184927@marcus-boerger.de>
To: Gregory Beaver <greg@chiaraquartet.net>
CC: internals Mailing List <internals@lists.php.net>
In-Reply-To: <479E1152.50301@chiaraquartet.net>
References: <479E1152.50301@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: re-proposal of pecl/phar for inclusion in core
From: helly@php.net (Marcus Boerger)

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