Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68557
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
In-Reply-To: <CAESVnVoB-38am-2bWfCYcCKKjiPVGUP34aYjdMADsR3inijBBA@mail.gmail.com>
References: <CABXB=RS6uL-d+0HbPpYxczw7jeijxu4s1TW5Lp_8fDvmafXS0w@mail.gmail.com>
	<CAESVnVoB-38am-2bWfCYcCKKjiPVGUP34aYjdMADsR3inijBBA@mail.gmail.com>
Date: Fri, 16 Aug 2013 14:03:43 -0400
Message-ID: <CABXB=RQKhFxCRmOO1QhpejX5EvaDfjE+sK9ybTFV-On0+ukuag@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
From: j.david.lists@gmail.com (J David)

On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon <pollita@php.net> wrote:
> Apart from managing lifecycles, the SAPI is also resposible for things li=
ke
> directing I/O between the host application, how does null-sapi handle thi=
s?

It doesn't.  It provides no SAPI functionality at all (hence "null").

Its only purpose is to allow building SAPIs separately from building
PHP by leaving all that stuff out.  The sapi_module_struct and all its
callbacks -- including but not limited to I/O handling -- are provided
later by the externally-built SAPI.

This offers several benefits:
- it makes embedding PHP easier and more flexible.
- it allows new SAPIs to be developed and distributed independently of
the PHP source tree (i.e. as part of a web server or as a separate
package)
- it (hypothetically) makes SAPIs modular and able to be selected at
runtime rather than build time
- (therefore) it allows multiple SAPIs to coexist in a single installation

Obviously our use case is the first/second.

The last two benefits are hypothetical, since they would require
existing SAPIs to be tweaked.

E.g. currently the CLI SAPI and the apache2 SAPI can coexist, but they
do so by building the entire PHP runtime into both =85/bin/php and
=85/apache/libexec/mod_php5.so.  If they were tweaked to build with
null-sapi:

- the "main" build would be null-sapi which produces only libphp5.so
with no SAPI code
- the CLI and apache2handler SAPI's would be built after/separately
from the "main" build, like extensions
- the CLI binary and mod_php5.so would both link to the same shared
libphp5.so at runtime, instead of the current approach where they both
contain the entirety of PHP.

Modifying the existing SAPI's would be a bigger step and may not be
desirable for other reasons.  It isn't something we have pursued or
consider necessary; the first two benefits were sufficient for us to
justify doing this.  But the issue of building multiple competing
SAPIs from one tree does come up from time to time, so if you want to,
imagine a possible bright future world of arbitrary happily coexisting
SAPIs. :)

Thanks!