Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 85.214.94.56 cause and error)
Date: Mon, 7 May 2007 21:15:30 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1377895609.20070507211530@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, internals@lists.php.net
In-Reply-To: <463F74EA.7030704@zend.com>
References: <139872287.20070504170744@marcus-boerger.de> <9DC00D11-00A5-40DB-A397-8454C48FA448@prohost.org> <1525138013.20070504193205@marcus-boerger.de> <463B70A1.4010505@zend.com> <463B7232.7000205@php.net> <463B8B36.5010906@zend.com> <1992195966.20070504214413@marcus-boerger.de> <463B9271.3040009@zend.com> <1348470081.20070504221609@marcus-boerger.de> <463EB3FD.4020009@zend.com> <1062653277.20070507092725@marcus-boerger.de> <463ED871.8080606@zend.com> <463F1B3A.3070703@pooteeweet.org> <463F74EA.7030704@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: helly@php.net (Marcus Boerger)

Hello Stanislav,

Monday, May 7, 2007, 8:50:18 PM, you wrote:

>> So if you are wondering about use cases, the PEAR installer is a good 
>> example. Generally I would say phar lends itself for self installing 

> Let's separate phar as installer format and phar as runtime format. Only 
> problem I have with the former is that it's custom NIH-syndrome-enabled 
> format which no tools except PEAR can work with. I don't have any 
> problem with the idea of having distribution format inside PHP toolkit 
> or the intent of the project, on the contrary - I think it's a great 
> think that should be taken even further - probably up to something like 
> InstallShield.php ;)

Phew, good.

> As for phar in runtime I think moving away from filesystem would create 
> more problems than solve. Of course, there are people that think the 
> opposite.

Agreed. It may often bring a bunch of problems. However being able to
have some stuff kept in a package, like a database driver, is a good
thing. This is actually what is donewith most JARs. If we could do that
with the same format we use as a distribution format, then suddenly some
nice stuff is possibly. You use phar packaged fileto download some
packages that you only use as includes. Now you keep them in your web
space, disallow access to ".phar" and include the actualfiles via
"phar://...phar/...". As a sideeffect you can easily check that the
package doesn't get changed. Now please note that from the beginning,
I did not say that this is something we should promote as the absolute
best thing. I am only saying that this is an option the pahr extension
offers.

>> Also it is one of those cases of "build it and they will come". So once 
>> we put this into core, people will take notice, tools will be developed, 
>> others will be adapted to become compatible etc.

> We don't need phar extension in the core to make phar installer, as far 
> as I understand.

We will need it:
- by the time of PHP 6
- to be able to have PHARs without pretty big PHP_Archive stuff included
- "include phar://" run easily and always

And just to be certain, we are not trying to force anybody to use it.

Best regards,
 Marcus