Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68558
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.192.177 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CABXB=RQKhFxCRmOO1QhpejX5EvaDfjE+sK9ybTFV-On0+ukuag@mail.gmail.com>
References: <CABXB=RS6uL-d+0HbPpYxczw7jeijxu4s1TW5Lp_8fDvmafXS0w@mail.gmail.com>
	<CAESVnVoB-38am-2bWfCYcCKKjiPVGUP34aYjdMADsR3inijBBA@mail.gmail.com>
	<CABXB=RQKhFxCRmOO1QhpejX5EvaDfjE+sK9ybTFV-On0+ukuag@mail.gmail.com>
Date: Fri, 16 Aug 2013 14:28:26 -0700
Message-ID: <CAESVnVr86ZYYUcqUwLCQ0WPzLFpah6dW9H+mAucc7F=jsubarA@mail.gmail.com>
To: J David <j.david.lists@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b15ab7f687eaa04e417455e
Subject: Re: [PHP-DEV] Interest in a "null" SAPI for embedding?
From: pollita@php.net (Sara Golemon)

--047d7b15ab7f687eaa04e417455e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Ah, I see.  I wasn't taking "null" quite literally enough. :)

That sounds pretty awesome to me.  Assuming the implementation looks good
you'd get my vote.


On Fri, Aug 16, 2013 at 11:03 AM, J David <j.david.lists@gmail.com> wrote:

> 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
> like
> > directing I/O between the host application, how does null-sapi handle
> this?
>
> 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 installatio=
n
>
> 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!
>

--047d7b15ab7f687eaa04e417455e--