Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.147 cause and error)
Message-ID: <009c01c89a24$4d88f2e0$4001a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Gregory Beaver" <greg@chiaraquartet.net>,
	"Lars Strojny" <lars@strojny.net>
Cc: "php-dev" <internals@lists.php.net>,
	"Marcus Boerger" <mail@marcus-boerger.de>
References: <47ED6D97.3030109@chiaraquartet.net>	 <1206788577.3621.15.camel@localhost>  <47EEC989.5020603@chiaraquartet.net> <1206839984.3621.71.camel@localhost> <47FC4A83.6080205@chiaraquartet.net>
Date: Wed, 9 Apr 2008 10:30:05 +0100
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] practical phar considerations
From: steph@zend.com ("Steph Fox")

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