Re: phar: problem with renaming implementation
| From: | Steph Fox | Date: | Sat, 22 Mar 2008 22:38:55 +0000 |
| Subject: | Re: phar: problem with renaming implementation | ||
| References: | 1 2 3 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-5244@lists.php.net to get a copy of this message | ||
Hi Greg,
OK...this is the only way to compress all files inside a zip archive (which are uncompressed by default in phar), and is the only way to generate a phar-based phar archive that has compressed files which can still be run without ext/phar, as whole-file compression would compress the stub as well. So, yes.compressAllFiles*() would go back to its original purpose of compressing individual files within the archive (and would throw an exception if called for tar-based phar archives).I'm not 100% sure what you mean by that... Does anyone (except you presumably) knowingly compress each separate file within an archive?
In that case can we have compress() _and_ compressAllFiles(), since they actually do different things?Altogether, if we're revamping that part of the API I'd like to keep it simple for the casual user: compress(Phar::GZ|BZ2) - returns a handle to the compressed file or FALSE isCompressed() - returns Phar::GZ|BZ2|FALSE either of 'uncompress()' or 'decompress()' - returns a handle to the decompressed file or FALSE - this the same naming for Phar, PharData and PharFileInfo. If you _also_ want compressAllFiles() and it means something different, bags you do the docs for it :)The existing docs already describe what it should do.
Ah, gotcha.if the filename changes, how does the enduser know what the new filename is? exposed.Finally, we need a method for grabbing the phar filename.? internal or exposed? (Not entirely sure what you mean here either.)
Cool... I expect to have my bits complete by the end of next week, including these changes. (Ever the optimist!) - StephGood. I've got 5.2 working, and am finally tackling the bugs at pecl.php.net. The next step is going to be getting that ZF app working and then we'll be ready for a release of the 2.0 strain to get these new features more battle-tested.Discussion should ensue, and I'm also curious whether you want to take this on Steph? It should result in MUCH simpler code and logic for our debugging purposes as well as in the end-user PHP level.More than happy to - relieved, even - with the caveat that I'd like those bits I'm not clear about, clarified. Apart from that, you just keep up the rear end with the battle for stream wrapper access to include_path ;)
Greg -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php