> From: Greg Beaver [mailto:[EMAIL PROTECTED] > With all due respect, this is a rather severe exaggeration of > PHK's talents. > > PHK does *not* use a standardized file format like ZIP, and > the format is undocumented as of last Friday when I read all > of the docs at your site.
Right. As for phar, I didn't find a format to support every features I wanted. You're right, it does not solve EVERY issues people raised about phar :) The main problem, as you know, is to find a format which allows the archive file to be included as a PHP script file. And I also wanted to be able to set an 'interpreter' line (a line starting with '#!') at the beginning of the file. If somebody knows a format which supports that, please tell me. > PHK source code is not easy to find (is it even publicly available?) Wrong. PHK source code is contained in the PHK_Creator package (which inserts it in every package it creates). Either you extract it from the PHK_Creator PHK file, or you download the PHK_Creator building kit: it is quite the same but in tar format, with the Makefile and PSF file used to create the creator package. > PHK source code does not adhere to any coding standard I've > ever seen before. Right. I am currently modifying it to become conform to PEAR standards. > PHP_Archive (the equivalent to PHK) is only needed to create > the .phar archives, just as PHK is needed to create PHK > archives (no difference - external tool needed) but in both > cases nothing is needed to run the resulting archives. I don't understand. In order to be able to include a phar archive, the phar stream wrapper must have been defined previously, either by PHP_Archive or by the PHAR extension. When you include a PHK archive, you just need PHP version 5.1 or more, as the runtime code is included in the archive. And, when the accelerator will be available, it will be the same : the embedded runtime code will detect the optional accelerator and use it transparently. > PHK is developed by one developer without the benefit of > community oversight, or any evidence of interest in > community-based open source development at all. This is unfair. I tried to get interest from PHP core developers from the beginning, 18 months ago. The only replies I got were rude ones, 'what's wrong with phar ?' style. How can you speak of 'community oversight' when I COULD NOT get any interest from the community! From the beginning, everything is available on my website, there are now more than 50 pages of documentation about PHK. I also registered the project on freshmeat, sourceforge, and hotscripts. What can I do more ? You want to know me personnally ? I'd love to go to PHP conferences but I can't afford. I am living in France, and even european events are too expensive, considering hotel and travel. Please understand that I am an independant contractor, without a company to pay for it. Something else: I proposed PHK as a conference subject for almost every PHP events since 12 months. In most cases, I didn't even get any reply. In France, it was refused and people even told me that they were looking for 'serious' subjects... Now, I don't propose it any more as it is too frustrating. It helped me to understand that the PHP core community is a very closed group of 15-20 people. Of course,it is important to know each other, but you should be more open to ideas coming from the outside. Every time I submitted something on the mailing list, the rare times where I got a reply, it was just to destroy my ideas. And I am not the only one, when I see the tone of some messages, I am really ashamed. PHP needs fresh ideas. Too many people reply things like 'I am not presonnally interested by this feature, so nobody is', as in this thread... As an 'evidence of interest in community-based open source development', I also proposed PHK to the Zend Framework project, building the packages, integrating the unit tests, writing an RFC to demonstrate the benefits it can bring. Yes, it is 'developed by one developer', but it is not a choice, believe me. If somebody wants to help with the accelerator extension, he is welcome ! I don't take this as an argument, but PHAR has been developed by 3 developers, now 2 active, with very little community interest and oversight... > > The advantages PHK possesses are > > 1) snazzier looking website > 2) integrated introspection (which cannot be "disabled" at > packaging time no?) PHP_Archive does not require > introspection but assumes the programmer would write it - > something that would be a wonderful addon. No, the introspection code cannot be disabled at packaging time, as it must remain an integral part of the package and a standard feature. > 3) built in front controller. A front controller is easy > enough to write I did not consider it necessary to enable one > by default, but this is not a bad idea as an optional > accessory for beginning users. I don't see it as an 'optional' accessory for beginning users. Some prominent PHP software like phpmyadmin can be run as a single file through this controller. And it is not so easy to write, especially if you ant to provide features like path protection, transparent access/redirection, mime types, default page... > 4) interesting idea of "mounting" archives (not quite sure if > this requires the use of PHK_Util to load archives or works > with native require_once? Explicitely using the mount points or even the phk stream wrapper is an advanced feature in PHK, as it provides more advanced tools to solve general-purpose cases. Using PHK_Util is not needed to mount an archive as including it first mounts it, before returning the mount point. > 5) easy docs on how to use it > > The phar extension provides #5 at a more complete level than > PHK (i.e. file format is documented) at http://www.php.net/phar As I said previously, the PHK documentation now contains more than 50 pages. I don't consider it as less complete than phar's one just because the file format is not explained yet. I can write a document describing the file format and I will, but do you really think it is a priority ? Do you really think that it can help people adopt PHK ? IMO, working on the accelerator extension is more important. Also, the PHK PHP API is not documented yet and the main reason is that most users and packagers never have to read it, as PHK provides higher- level features wich are sufficient for 99% of real-world cases. For instance, every demo package present on the website can be engineered without using the PHP API. They all use only higher-level features, and you cannot say they were choosen to be especially basic ! > PHK does not solve the issues that PHP_Archive has which is > it too will stop working in PHP 6. Right. But I don't have the same analysis about it: IMO, the decision that was made for PHP 6 is absolute nonsense. Once again, a small group of people decided for themselves without thinking enough. Deciding that every user stream is remote is a narrow-minded view of user streams. So, I consider that I am right and that this decision must be changed before PHP 6 is released. I understand that, as Stefan Esser was putting the pressure on security, people could make this kind of decision but, now, it is time to find a better approach to stream wrapper security (and maybe to PHP security in general). And, if they don't, unfortunately, it will be one more reason not to switch to PHP 6 :) Best regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
