Sorry, php-internal guys, just a small :) reply to Greg's message, and we'll take it off list, as Greg is right: it does not have much to do with php internals any more...
> From: Greg Beaver [mailto:[EMAIL PROTECTED] > Please STOP spreading misinformation. phar is *not* a > deployment tool, even though it can be used this way. I am sorry if you took it this way. I just meant: 'if you are looking for a deployment tool, please DON'T choose PHK. A POSSIBLE solution is to use phar as it ALSO supports this feature'. I really never implied that phar is just a sort of 'auto-extracting' deployment tool. If someone understood it this way, I sincerely apologize for my bad written english. There is another point where I think I was misunderstood: IMO, there is no competition between phar and PHK, as I think there are good things to take in both for an eventual future merge. The only difference in the approach is the perimeter definition. What do we provide and, especially, where do we stop ? What is our audience ? > PHP_Archive/phar has limited its audience to all users of > PHP, and rather than prescribing a rigid model that all phars > must conform to, PHP_Archive/phar allows both simple and > advanced usage. PHK expects all users to do things the same > way. This is the difference. > To expect that some kind of generic code will always work for > every web app is midguided at best. By limiting PHK to this > behavior, you are in fact limiting PHK to distributing a few > applications. The challenge, here as in almost every software, is to provide intuitive, easy-to-use features for most users, along with some more advanced features and low-level APIs for advanced users. IMHO, this is the main recipe for success and PHP is a perfect illustration os such a success. And this is not a 'PHK/phar for dummies' approach. I may have given the impression that PHK enforces a rigid M$-like way of building packages, as I put an emphasis on how simple it is to build a PHK package using high-level features. But all these are optional and nothing is rigid. PHK ALSO PROVIDES high-level features. Everything is configured through options: if you want to provide you own controller, you can, and everything that can be done with phar can be done with PHK. I don't put limits, I provide solutions. None is mandatory, even if the documentation on low-level APIs is not complete yet. > the phar extension fully supports signing using md5 and sha1, > with plans for gpg signing in the near future. I don't see how md5/sha1 signatures can provide some security when used in this context. Sincerely, I may be wrong but I don't imagine a scenario where an md5 signature on a file in a phar archive will protect against intentional package corruption. If we just check against non-intentional package corruption, CRC checksums should be enough, no ? Please correct me as I maybe missed something there. Certificate-based signatures are different, but they also cannot be checked by the runtime code if it is included in the package. > The choice of PHK vs. pecl/phar is a straw man: PHK will not be > included in PHP core simply because it isn't C. This is not my goal here. I never requested PHK to be included in the core, not even the accelerator extension. Actually, we're certainly both right and wrong on what users expect from a packaging tool. Personnally, I just want to give them the possibility to make a fair choice for their own cases. Then, with more return from real users, I hope we can start a merge. Best regards Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
