Andi Gutmans wrote: >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
