Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30797
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sci.fi from 63.208.196.171 cause and error)
Message-ID: <469562DD.2030601@sci.fi>
Date: Thu, 12 Jul 2007 02:08:13 +0300
Reply-To:  jani.taskinen@iki.fi
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Tijnema <tijnema@gmail.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <d8269d910707111543t3d8ea2a1ga38f8857a6836618@mail.gmail.com>
In-Reply-To: <d8269d910707111543t3d8ea2a1ga38f8857a6836618@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Apache handler with Multiple PHP versions
From: jani.taskinen@sci.fi (Jani Taskinen)

A lot easier (and works already) is to install PHP as CGI/FastCGI
(one version or all of them, one can be module of course) and define the 
required PHP version by the file suffix..

--Jani

Tijnema kirjoitti:
> Hello developers,
> 
> The thread about dropping support for PHP4 gave me a new idea, having
> multiple PHP versions to be loaded by the Apache2handler SAPI.
> 
> The idea:
> I was thinking about something like the shebang(#!) line used in
> bash/perl/python and even PHP scripts. But this time not for the
> program to be executed, but for which PHP version to load. This could
> be used like this:
> <?php // PHP4 ?>
> for PHP4, and so it could be
> <?php // PHP5 ?> or <?php // PHP6 ?>
> for resp. PHP5 or PHP6.
> This way can scripts define which PHP version they require, as it is a
> normal comment line, other PHP version can simply ignore the line.
> 
> The implementation:
> The Apache2handler SAPI should be loaded first, and read the very
> first line of the PHP script to determine if a version is specified
> there. If not, the handler needs to load its default PHP version. If
> it is specified, it should try to load that version, and if it
> couldn't find or load that version, fall back to the default version
> and issue a warning.
> 
> What needs to change:
> Currently, PHP is one big module for Apache, which will load a full
> PHP version at once. For this, we require a very small handler, that
> will use dlopen() to load the appropriate version and continue with
> the execution of the PHP script.
> Some kind of mini parser is also required to read the very first line
> of a PHP script, because that needs to be done before any PHP version
> is loaded. And maybe also a parser for the php.ini file, as php.ini
> needs an extra option for the default PHP version to be loaded, and
> one or more settings for configuring the different PHP versions and
> their path to the library.
> 
> Some extra ideas, not sure if they need to be implemented:
> * Support for sub versions of PHP, like this:
> <?php // PHP4.3 ?>
> <?php // PHP5.2.1 ?>
> * Support for multiple possible PHP versions, like this:
> <?php // PHP4 || PHP5 ?>
> Where the first one is the preferred one, which can also be combined
> with the first one of course, like this:
> <?php // PHP5.2.1 || PHP5.2.0 || PHP 4.3 ?>
> * Support for <, > and && signs in the version, like this:
> <?php // PHP > 5.2 && PHP < 5.3 ?>
> So that any PHP version between 5.2 and 5.3 fits, but that 5.2 is the
> preferred one, if 5.3 should be the preferred one, it should be
> written like this:
> <?php // PHP < 5.3 && PHP > 5.2 ?>
> * Support for this in other handlers, like FastCGI, ISAPI, etc.
> 
> 
> It seems to be the perfect solution for shared hosting providers to
> me, as it will allow the user to select which PHP version he wants to
> use, and shared hosts can just install all three versions of PHP and
> use the one they need for their admin panels etc. (One of the reasons
> against upgrading to PHP5), and users can use another version.
> I don't know too much about PHP core, and nearly nothing about the
> apache2handler, so if it's not possible, please excuse me for wasting
> your time.
> But, if it is possible, I will definitely go deeper inside the core
> and SAPI code to get it working.
> 
> Now, the reason I'm sending this to the list is that I need to know if
> *) it is possible?
> *) it is not yet done
> *) it is wanted
> *) it will have any negative effect on something?
> 
> I'd like to hear all your comments and objections on this, and of
> course, if you have any question, feel free to ask.
> 
> Regards,
> 
> Tijnema
>