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.
