Marcus Boerger wrote: > Hello Steph, > > so you mean we do not have to confuse our uses by solution 2a becasue we > only have the minimum subset of zip in phar that ohar actually needs? > >
Although phar can be used to create and read any zip archive, it will automatically add the file ".phar/stub.php" when creating or modifying a zip file, as this file is needed in order to directly run a zip-based phar archive. Although this could be disabled to make phar ext/zip, I don't think phar is the right API for simple data-based zips. For one thing, write access is disabled by default, meaning on-the-fly creation of zip/tar in web applications is disabled by default. Phar is designed with the idea that one creates the phar archive on a development machine and users just use it read-only. This is most important for phar-based phar archives, as these can run without ext/phar being present. One possibility that just occurred to me would be to allow creation of zip/tar files that do not contain ".phar/stub.php" if phar.readonly=1. These archives would not be executable because of this omission, and it would allow creation of tar/zip via phar in any application. However, this may be too confusing with the current API. One possibility is simply to provide PharZip/PharTar objects that can only work with tar/zip-based archives and allow creation of non-executable tar/zip archives. This would require minimal code changes, probably just a line or two for each object as we could use the existing Phar object as its base and a simple flag. In terms of minimum subset, phar supports nearly the full range of possibility with zip archives currently (encryption is the only major feature missing), and I'm not sure how we could successfully subset that without obfuscating the code. Steph's reference to test failures is simply that some of the existing tests use ext/zip to create zip files on the fly, and then pass those to phar, in order to test phar's ability to take a fully created zip file as opposed to one it made itself, and is not a user issue, just a structural issue in the tests themselves that has nothing to do with phar's zip support. The tests simply need to be modified to create the zips using pecl/phar and copy the filename to one phar doesn't already know about, and the failures will go away. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
