Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29348
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Marcus Boerger <helly@php.net>
Message-ID: <4640CC76.7090104@php.net>
Date: Tue, 08 May 2007 15:16:06 -0400
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
CC: Andi Gutmans <andi@zend.com>, Stas Malyshev <stas@zend.com>, 
 Edin Kadribasic <edink@php.net>
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> <698DE66518E7CA45812BD18E807866CE2FEE88@us-ex1.zend.net> <1291095925.20070504220553@marcus-boerger.de>
In-Reply-To: <1291095925.20070504220553@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: davey@php.net (Davey Shafik)

When I first wrote PHP_Archive the entire point of the stub script was 
to handle incoming requests, just like the multitude of applications 
that have everything go through "index.php" (S9Y for an example).

Using Phar with MultiViews and mod_rewrite is just same as funnelling 
everything through a single regular PHP script, this was one of the 
design goals and is a very common practice.

The main difference here, is with web applications you have non-HTML 
resources you must also handle - this WILL incur a performance hit over 
serving them as a static page. But applications like S9Y, FUDForum, 
phpMyAdmin where the *typical* usage is not to serve a large number of 
users, this is usually not an issue.

These techniques work just fine.

- Davey

Marcus Boerger wrote:
> Hello Andi,
> 
> Friday, May 4, 2007, 9:55:23 PM, you wrote:
> 
>> I think phar is a nice idea but honestly haven't had enough bandwidth to
>> check it out in more detail. Has there been some thorough analysis on
>> the performance impact of it and whether this is the optimal recommended
>> way for our users to distribute apps? The idea is actually very
>> interesting but we should be pretty certain we're doing the right thing
>> before we distribute it. We can spend some time looking at it in more
>> detail.
> 
> You guys spent a good effort in such analysis in the past. Would be very
> nice to hear something in that direction from you.
> 
>> Btw, it seems to me that because of the way Apache works for most of our
>> users it actually won't be that useful and just act like a .tar archieve
>> which needs to be extracted. This is unless the user implements some
>> kind of front controller. It would really be nice if we have the 99%
>> common Apache application use-case figured out and docuemnted before we
>> put our PHP dev team weight behind it. Or am I completely missing some
>> magic here?
> 
> not at all. It perfectly works for includes. But i have no idea how to use
> it from a url directly...well you can provide some tricks. But i wouldn't
> recommend those.
> 
>> Andi
> 
>>> -----Original Message-----
>>> From: Marcus Boerger [mailto:helly@php.net] 
>>> Sent: Friday, May 04, 2007 12:44 PM
>>> To: Stas Malyshev
>>> Cc: Edin Kadribasic; internals@lists.php.net
>>> Subject: Re: [PHP-DEV] [RFC] Starting 5.3
>>>
>>> Hello Stanislav,
>>>
>>> - you don't need a tool - well php - but hey you probbaly 
>>> have that tool
>>> - you can run phar archives out of the box - untouched
>>> - you can extract phar archives and run them - still untouched
>>> - you can provide phar archives that do not require a phar extension
>>>
>>> To your question "is phar so important that everybody needs 
>>> it in the main source." I think the above means it should.
>>>
>>> best regards
>>> marcus
>>>
>>> Friday, May 4, 2007, 9:36:22 PM, you wrote:
>>>
>>>>> obsolete set of tools (autoconf-2.13, etc.). Having Phar 
>>> in the main 
>>>>> distro will open up a whole new way to distribute PHP applications 
>>>>> which would be a great advantage. The current system of 
>>> distributing 
>>>>> a bunch of PHP files has some shortcomings.
>>>> I'm personally not sure phar is that great way of 
>>> distributing apps - 
>>>> it's yet another format not supported by standard tools and I don't 
>>>> really see much of an advantage to using it versus just making a 
>>>> package with any of the existing package formats and I see 
>>> a number of 
>>>> disadvantages - non-standard format, hard to work with 
>>> packed scripts 
>>>> with available filesystem tools, etc. But that's my opinion and I 
>>>> fully expect some people to hold exactly the opposite opinion. The 
>>>> question is however is phar so important that everybody 
>>> needs it in the main source?
>>>> --
>>>> Stanislav Malyshev, Zend Products Engineer stas@zend.com  
>>>> http://www.zend.com/
>>>
>>>
>>>
>>> Best regards,
>>>  Marcus
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List To 
>>> unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
> 
> 
> 
> Best regards,
>  Marcus