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.li...@gmail.com> wrote: > On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon <poll...@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 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! >
