Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95654
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
To: Michael Morris <tendoaki@gmail.com>, internals@lists.php.net
References: <CAEUnE0fnCT5-J6+Loy-s1gxxaAouDb7TgBNBMg3OoxpnWS8JyA@mail.gmail.com>
Message-ID: <91b9f8b2-906a-72c9-0960-047efca52028@gmx.de>
Date: Mon, 5 Sep 2016 18:16:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAEUnE0fnCT5-J6+Loy-s1gxxaAouDb7TgBNBMg3OoxpnWS8JyA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Single Point of Entry Apps.
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 05.09.2016 at 18:03, Michael Morris wrote:

> Something I was reminded of during the discussion of replacing pear with
> composer that I thought was worthy of it's own thread.  Most PHP apps I've
> seen that use composer are
> single point of entry apps - that is there's one front controller, usually
> index.php, and .htaccess rules are put in place that route all requests to
> that file.
> 
> These apps then go through the process of initializing themselves and
> sometimes there are thousands of lines of code that get parsed through
> before the app is in ready state, the router finally loaded and a decision
> is made concerning the user's request.
> 
> This is extremely inefficient
> 
> What can be done in PHP core to more effectively embrace this paradigm
> without disturbing the current one?  That's what this thread is to
> discuss.  Here's my stab at it.
> 
> Create an .htaccess directive that allows a php file to be a directory
> handler.  When that directive is set the webserver will pass any
> non-existent file request to PHP (in effect becoming a one line replacement
> for a very common usage of mod_rewrite).
> 
> When this directive is used two statements will be looked for by the
> runtime - first a ready statement (not necessarily named "ready"). When it
> is reached PHP will save the application state, clone it and continue
> working from the clone. On all all subsequent requests to the directory PHP
> will start by creating a new clone and working from there.
> 
> The second statement instructs PHP to drop the saved state and load a new
> one starting with the next request (graceful) or to kill any concurrent
> workers (panic)
> 
> This isn't the same as opcode caching - this would be caching of the entire
> application state including any data harvested from config file reads or
> database calls.
> 
> It is possible to create this setup now using some PHP worker process
> trickery, but it isn't easy.
> 
> Again, the above may not be a possible solution - but there's got to be a
> better way than the current approach which amounts to installing the
> application on every single request.
> 
> Thank you all for your time.

Not long ago (something like) this has already been proposed, see
<http://news.php.net/php.internals/92249>ff.

-- 
Christoph M. Becker