Re: practical phar considerations

Hi Greg,

What I would like to do, however, is to rethink offsetSet(). I think that we should introduce a property of PharFileInfo called "content" that is read/write, and can be used to perform the equivalent of file_get_contents()/file_put_contents(). This will allow a consistency that is much more intuitive. offsetSet() could then simply be removed, or perhaps be refactored as a way to pass in a PharFileInfo and clone the information.

Could you offer up some pseudo-code showing how this will be used? I can't visualize it at all from that description.

One problem with this suggestion is that phar renames the archive by default when compressing. I would rather we combine compression and format conversion into a single convert() method that accepts constants. $phar = new Phar('blah.phar'); $phar = $phar->convert(Phar::GZ); // compress with gzip $phar = $phar->convert(Phar::TAR | PHAR::GZ); // convert to .phar.tar.gz $phar = $phar->convert(Phar::NONE | PHAR::DATA); // convert to non-executable .tar, returns PharData object $phar = $phar->convert(Phar::EXE); // convert back to .phar.tar

Didn't we just go full circle here? There was a proposed convert() method that did absolutely everything (on e-paper) and it was far less intuitive than when conversion was separated from compression. That's why you ended up implementing them separately, as I recall.

This would also solve a subtle but important problem with the current conversion API where intermediary files are lying around.

Can't we simply delete those intermediary files on success? That would be the normal procedure when renaming, no?

Do you want to take a crack at a patch for any of these API features once they are worked out (buildFromDirectory should be an easy one, if you would like to start there)?

Yes, I'm willing to help with it to a degree, as I said in a previous mail.

How soon can we expect a patch for this? Steph also expressed interest, and we are on a rather tight time schedule to get this to beta, which will mean a feature freeze (no new crap, just bug fixes).

I'll implement buildFromDirectory() this weekend. It would've been last weekend, but I got caught up in trying to bring the last few non-core PECL modules into line over versioning structure, which hasn't been entirely plain sailing. (Still 5 + IBM to go.) - Steph