Re: phar: problem with renaming implementation

From: 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,
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?
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.
OK...
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.
In that case can we have compress() _and_ compressAllFiles(), since they actually do different things?
Finally, we need a method for grabbing the phar filename.
? internal or exposed? (Not entirely sure what you mean here either.)
if the filename changes, how does the enduser know what the new filename is? exposed.
Ah, gotcha.
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 ;)
Good. 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.
Cool... I expect to have my bits complete by the end of next week, including these changes. (Ever the optimist!) - Steph
Greg -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php


« previous php.pecl.dev (#5244) next »