RE : [RFC] Starting 5.3

> From: Stanislav Malyshev [mailto:stas@zend.com] > > Actually, I would say it would be better to have some "minimized" > version which is extract-only, has all the comments stripped, > etc. for > inclusion in the archives. There's a difference between phar and PHK here. PHK is not a deployment tool. Because of the high-level features it provides at runtime (as the autoloader, access protection, and others) and also as a design choice, a PHK archive is distributed and runs as-is. If you want a deployment tool, take phar or any other 'auto-extracting' script available, but please don't use PHK for this. Well, actually, it is possible to extract the files from an archive. It is provided as a built-in utility feature, but just to view the files, not to run them after extraction. I don't want PHK to be used as a deployment tool because one of its main goals is to make sure that, once it is packaged and distributed, your application/library will keep its integrity. The configuration files are put outside of the archive and the archive is viewed as a virtual read-only file tree. This is quite the same as a binary executable file, even if we are in an interpreted world here. Would you consider it serious if you had to recompile your httpd file, for instance, after any configuration change ? No, you are used to have a never-changing httpd and, somewhere else, your configuration files. PHK tries to enforce the same philosophy. It is not just a sort of PHP-oriented tar-like toolbox like phar, it tries to provide a high-level service to package maintainers, allowing them to distribute their applications in a cleaner way than what is possible today. And I am currently going further this way as I am currently adding a built-in feature to extract default configuration files from a package at runtime. This way, the package designer will just have to where the default conf lies in the virtual tree, and the user will have a standard way to extract them on installation. Another example of this philosophy is the ability to digitally sign a PHK package, as it is another way to get sure that the file won't be modified after it is distributed by a trusted source. We can argue endlessly on the case as, on one side, Greg and Marcus seem to consider that these high-level features (which represent 90 % of PHK) are just small easy-to-do additions to phar-like features, and on the other side, I do consider that it makes a huge difference for the typical phar/PHK user. Once again, if I had done PHK for my exclusive use, I would have stopped at the same feature level as phar. But I am not interested in a project where I limit the audience to php-internals members :) It is just a choice. Now, php-internal members, read the docs, try both tools on YOUR software, compare the time and efforts it took in both cases, and make your own opinion. But, please, make a TECHNICAL choice, don't base it on friendship or personal links. Best regards Francois