Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68547
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
Date: Fri, 16 Aug 2013 12:36:41 -0400
Message-ID: <CABXB=RS6uL-d+0HbPpYxczw7jeijxu4s1TW5Lp_8fDvmafXS0w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Interest in a "null" SAPI for embedding?
From: j.david.lists@gmail.com (J David)

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!