Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <46E622F6.5000208@chiaraquartet.net>
Date: Tue, 11 Sep 2007 00:09:10 -0500
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: Andi Gutmans <andi@zend.com>
CC: David Coallier <davidc@php.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <6F509818-65A2-4B17-8C44-6970E815A169@prohost.org> <698DE66518E7CA45812BD18E807866CEA2AE39@us-ex1.zend.net> <46E5B223.5070406@chiaraquartet.net> <698DE66518E7CA45812BD18E807866CEA2AE65@us-ex1.zend.net> <b5f7bf6c0709101605v38776a07qc94aab67a8d93677@mail.gmail.com> <698DE66518E7CA45812BD18E807866CEA2AF4D@us-ex1.zend.net>
In-Reply-To: <698DE66518E7CA45812BD18E807866CEA2AF4D@us-ex1.zend.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Why not jar for phar? (was Re: [PHP-DEV] PHAR was PHP 5.3 Suggested
 Feature List)
From: greg@chiaraquartet.net (Gregory Beaver)

Andi Gutmans wrote:
>> -----Original Message-----
>> From: david.coallier@gmail.com [mailto:david.coallier@gmail.com] On
>> Behalf Of David Coallier
>> Sent: Monday, September 10, 2007 4:05 PM
>> To: Andi Gutmans
>> Cc: Gregory Beaver; PHP Developers Mailing List
>> Subject: Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature List
>>
>> Andi, if there was to be a cross platform tool to view, extract, add,
>> etc with phar archives, would that influence your choice ?
>>     
>
>
> Well the point is that if you're using tar, zip (jar) or some other standard file format you have thousands of tools that you can use.
> The format is really mainly an implementation detail (maybe with some minor semantics) so I think it's better for PHP to embrace an existing one than coming up with its own. This is also why Java took this approach.
>
> I realize there is some history to this implementation but I think tweaking the file format part of the implementation isn't a large amount of work and worthwhile in the long run esp. as phar hasn't been widely adopted at this point (and probably won't be for Web apps but rather installations and administration solutions).
Hi,

I'd like to clear up some confusion.

Actually, phar works quite well in a web environment, I suggest we stop
talking about it as if it were just an installation stub.  There is even
a possibility that applications within a phar will be faster than their
filesystem equivalent when used with (as yet unwritten changes to) APC
because of the complete lack of a need to do any filesystem stats on the
files.

The implementation of the jar format would require changes to the Zend
Engine in order to work in the way that phar works, as there is no way
to use a PHP loader stub with a jar because it uses the zip file
format.  Even if we did go with another standard file format like tar
which the original PHP_Archive class used (A hack can be used to make
the first file into a PHP loader stub), for performance reasons the
structure of the file would still need to be specific to PHP's needs,
rendering all of those thousands of tools useless for anything but
looking inside of the file to see how it was implemented.  For instance,
the jar file format is a zip file with a customized manifest stored as
one of the files.  The same would be true of a tar-based implementation,
but even more customization would be needed as we would need to store
the index as well, something that is built into the zip file format.

I chose a different file format because it was a better choice both for
performance and usability than the existing formats out there, and
simply calling it "different" does not do justice to the reasons that
make it better.  The reason we do not do classes like java is because
PHP is not java, as many are very happy to say and rightly so.  Why turn
around and make the same arguments for phar?  Phar is not jar any more
than PHP namespace is C++ namespace.  It does not solve the same
problems as jar in Java, nor does it intend to solve the same problems.

Incidentally, pecl/phar already provides a cross-platform tool to view,
extract, add, it's called "phar.phar" and is run via "php phar.phar".  I
don't think it is quite feature complete, but this would actually take a
small amount of work to reach that point, much less than modifying PHP's
core to support the jar file format.

I am happy to look at other implementations of the file format if and
only if it can be shown to be worth the change, but I do expect the
courtesy of compelling arguments that take into account the work already
completed so that I'm not wasting anyone's time including my own.

Thanks,
Greg