Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Date: Mon, 5 Sep 2016 12:03:22 -0400
Message-ID: <CAEUnE0fnCT5-J6+Loy-s1gxxaAouDb7TgBNBMg3OoxpnWS8JyA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a114dfb1acde901053bc4d1b4
Subject: [PHP-DEV] Single Point of Entry Apps.
From: tendoaki@gmail.com (Michael Morris)

--001a114dfb1acde901053bc4d1b4
Content-Type: text/plain; charset=UTF-8

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.

--001a114dfb1acde901053bc4d1b4--