Hi, I've attached my PHAR variation that was made some time ago just to prove the concept. It uses standard TAR format and doesn't use any external libraries.
In case if you call "php test.tar.gz", PHP (with this extension) will execute file main.php from the archive. I cannot remember wich version of PHAR I used in benchmarks, but TAR was faster. Thanks. Dmitry. > -----Original Message----- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 11, 2007 1:43 PM > To: Andi Gutmans > Cc: Gregory Beaver; David Coallier; PHP Developers Mailing List > Subject: Re: [PHP-DEV] RE: Why not jar for phar? (was Re: > [PHP-DEV] PHAR was PHP 5.3 Suggested Feature List) > > > 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 >
php_tar.tar.gz
Description: GNU Zip compressed data
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
