I hesitantly say that the code change is "easy" however, performance will be absolutely miserable.
Unlike Tcl and its interpreted script model where a Tcl interp can be fed a Tcl script for evaluation, PHP is more like a stand-alone executable which executes a whole PHP script, like a Unix shell. It creates separate processes as necessary for script processing, and the PHP (Zend) engine is file-based.
Because of this, every call to the proposed "ns_php" command would fork the nsd process and start up a brand new PHP execution process. There would be no cohesion between two calls to ns_php, e.g., setting variables in one won't be visible in the next.
There's a highly experimental "embed" SAPI (server API) module for PHP, but after reviewing the code, it doesn't address the issues I've already mentioned.
In short, there's very little practical value in implementing a ns_php-like command for Tcl the way PHP is implemented today. And, given the design of PHP, I don't expect to see a PHP version that could be embedded considering how deeply rooted these design issues are. Perhaps, it'd be possible to lift the Zend engine and make it a proper embeddable script interpreter, but even with the new Zend 2.0 engine, they haven't gone in that direction.
For now, just be happy to be able to get back to the Tcl interp. from a PHP page -- that alone will make the AOLserver/PHP combo very powerful.
-- Dossy
