Hannes Magnusson wrote: > I still find Phar waaaaay to dangerous to _enable by default_ and I > still do not think you are *fit* to handle such extension. (Yes, I did > indeed say it. And I will not apologize for it. I really don't.) > ok. :] > You have your own agenda (just like everyone else), but your focus > isn't on PHP, or the Phar ext. > ? Conspiracy theories? I have plenty of public messages in the list archive (including php-cvs@) that show my focus *is* on PHP and the phar extension (as well as several that suggest my focus is on PEAR as well, including a book and a few magazine articles). Outside of my open source work, of course my focus isn't on PHP: it is on my family, and on my musical career. > It really does scare me. > I don't know of anyone that really actually does know what the ext is > capable of (and *I* know it is capable of *great* things. Seriously. > It could swing near the PHP3 "hit" all over again. The ext is > *definitely* a *great* extension.). > the manual is quite clear on what it can do, and there are no "hidden" features. Marcus developed most of the OO features, especially the SPL-related stuff. Steph heavily developed some of the buildFrom*() methods. The code could always do with cleaning up, which is why I try to subdivide functions and files where possible when I dive in to re-factor things. The only reason I haven't cleaned up further recently is because I'm trying not to touch it until 5.3 stable is out unless there is a problem. > Nothing against you personally, but when *noone else* knows wtf the > Phar ext is heading, or anything you do, I find your commits and > communications skills very freighting. Be it Steph or Pierre or > whomever tries to participate. It really does scare me. > Last I heard, the PHP 5.3 TODO contained this item: "make phar work with bigendian systems again."
There is no private agenda, and the CVS contains a file named "TODO" that we were using to track future feature requests. I haven't looked at it in a long time, because as I recall, all new features were added long prior to its proposal for inclusion. The only missing feature I know of off the top of my head is possibly some kind of "ReflectionPhar" to implement introspection, but this is not certainly planned for the near term, as everything is in feature freeze. This probably would not go directly into ext/phar, but would either be a new extension, or an addition to the reflection ext, but again, this is at least a year away if not more. > On to similar (related) topic: > Did you (or Dmitry) ever communicate? > Once upon a time I heard rumours that "Zend" had already experimented > with an extension "likish" Phar, using 'jar'. > Did anyone ever get "bencharmarks" or whatever from that experiment? > What about compared to Phar? > the only code I ever saw or heard of from Dmitry was a tar-based experiment. I based the tar file support in ext/phar off of Dmitry's proof of concept (which I requested on Sep. 10, 2007 and Dmitry mailed on Sep. 11, 2007), and Dmitry/Stas and I communicated regularly on a public basis on internals@ and through private messages to get phar to work with a zend framework-based app (Stas) and to fix performance issues (Dmitry). I sent several (lengthy) messages regarding phar's performance as compared to files on-disk, which is a better benchmark than other archive implementations, as the user wants a phar that smells the same as the files on-disk, and in my testing, phar was able to match on-disk when used with phar.cache_list and no opcode cache (opcode cache performance was slightly slower). The exact numbers are all in the emails I sent that are archived. Dmitry had mentioned he was able to verify these results, but did not post details, and I would love to hear if others have independently verified this or not. > I really *really* think we should hold off with Phar, at the very > least by default, for at the absolute very least one point release. > The filter extension was *important* extension. Maybe even as > important as (the future will tell) the Phar extension. But I do not > think it is ready. > > I really really don't. I would agree (and have in the past) if the facts support this. I think phar is not ready to be enabled on big-endian systems until the issues Scott discovered can be worked out. A quick scan of the bugs database reveals that phar's bug rates are comparable to other newly enabled extensions (such as fileinfo), and a severe drop-off in bugs reported since October, with more build bugs (.m4 problems, Makefile.frag problems) as people build phar on other systems. All of this suggests to me a strong stabilization of phar, not a serious problem, but if there is some information not yet reported to the bug tracker, then we need to report these bugs. I can't fix things if I don't know about them. I've heard enough bad-mouthing of ext/phar, and now of my character, that I will bow out of developing for PHP if this is what is desired. Clearly there is a small subset of developers who assume the worst of me, and there must be some reason for this I am not understanding fully. If I am the problem, I can accept this, and will resign without protest. I happen to believe that in fact the work I do is actually useful to PHP, and if this is delusion, then by all means, enlighten me. Otherwise, can we move on? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
