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 <[email protected]> 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
>
>