Re: Interest in a "null" SAPI for embedding?
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 <[email protected]> wrote:
> On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon <[email protected]> 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 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 …/bin/php and
> …/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!
>
Thread (15 messages)