Hello Andi, to end this 'many tools' reasoning. For those issues we already adopted zip and if people insist I wouldn't mind if anybody would provide a working tar implementation that allows reading of tgz and tar.bz2 files as well. Yest the purpose of Phar is very different. Anyway can it be that Dmitry was using an old version of Phar where indeed the performance was bad?
marcus Tuesday, September 11, 2007, 7:40:29 AM, you wrote: > Hi Greg, > I didn't mean to get you all defensive about it. I was just voicing my > personal thoughts on this subject as I did a few months back. It's just my > 2 cents and you're free to take it or leave it. > I think from a perf point of view the info Dmitry can send you may at > least give you some ideas on why we got better results with tar (and no, I > am not married to tar. I just thought it'd be nice to use something > standard so zip, etc. would be cool too). > Deployment is definitely a question-mark for me. Where can I find more > information on deploying a Web app using phar? Am I right to assume that > mod_rewrite is part of the equation? How is it done on Windows? > Btw, this isn't about making PHP into Java (which I'm the first to not > want to do) nor am I specifically calling out JAR. I'm just saying a standard > format would be nice. > And yes, I agree, it'd be nice to not have to make any significant changes in > the core for this. > Andi >> -----Original Message----- >> From: Gregory Beaver [mailto:[EMAIL PROTECTED] >> Sent: Monday, September 10, 2007 10:09 PM >> To: Andi Gutmans >> Cc: David Coallier; PHP Developers Mailing List >> Subject: Why not jar for phar? (was Re: [PHP-DEV] PHAR was PHP 5.3 >> Suggested Feature List) >> >> 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 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
