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?
On Fri, Aug 16, 2013 at 9:36 AM, J David <j.david.li...@gmail.com> wrote: > Hello, > > We recently successfully embedded PHP into our application using an > approach based on the embed SAPI. > > However, our application is large and complex, written entirely in > C++, requires a bit more functionality than the embed SAPI offers. > (As an example, however, it was invaluable.) So we needed a > customized SAPI, but there was no way it was going to build our live > inside the PHP source tree. > > Our solution was to develop a new pseudo-SAPI we call the null SAPI. > All it does is build a complete libphp5.so with no SAPI-related > structures or functions in it at all. Then we can build our real > embedded SAPI -- with all its extra dependencies and goofy custom I/O > handling -- outside the PHP tree and just link to the shared library, > rather than entangling our app's source tree and the PHP source tree. > > This was really very straightforward; creating an empty SAPI was > pretty easy and beyond that it only required changes to a couple of > build files. > > Is this something that would be of more general interest? It's not > clear if this is exactly the recommended approach, but it certainly > did work well for us and we would be happy to contribute the "work" (I > use this term loosely given the lack of difficulty) done. > > Thanks! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
