What Is Sapi and When Would You Use It

What is SAPI and when would you use it?

SAPI stands for "Server API" (and API stands for "Application Programming Interface"). It is the mechanism that controls the interaction between the "outside world" and the PHP/Zend engine. So, you would always want to use it. In fact, you cannot avoid using it without a lot of effort since even CLI is considered a SAPI.

Why is PHP CLI considered as a kind of SAPI?

"Why" is always a slippery, somewhat philosophical, question; ultimately, the answer to "why is CLI considered a SAPI" is "because that's how the developers defined it". If they'd called it "CLI mode", would you still have asked "why"?

But you do ask a more concrete question, which can be paraphrased as:

When running a program on the CLI, why do you need a SAPI as well as the Zend Engine?

Or even more succinctly:

What does the CLI SAPI do?

The Zend Engine on its own takes a series of instructions, and executes them. It can manage variables, arithmetic, function definitions and calls, class definitions, and so on. But none of those are very useful if you can't get any output from the program; and most commonly you want to provide some variable input as well.

Some forms of input and output are based only on the operating system you're running on, not the SAPI - reading or writing a file based on an absolute path, or accessing something over a network connection. You could theoretically have a running mode that only gave access to those, but it would feel very limited. (Would that still be a "SAPI"? Definitely a philosophical question.)

Consider something as commonplace as echo: there's no absolute definition of "output" that the Zend Engine can manage directly. In a web server context, you expect echo to add some output to the HTTP response the server will send the client; in a command-line context, you expect it to show the output in the console where you ran the command, or be "piped" to another command if you run something like php foo.php | grep error.

The CLI SAPI doesn't provide all the same facilities that a web server SAPI would, but it fills a similar role in interfacing your program, running in the Zend Engine, to the outside world. Here are a few of the things it needs to do:

Attach output to the parent console or "standard output" stream
Make the "standard input" and "standard error" streams available
Populate $argv and $argc based on the arguments the script was invoked with
Populate $_ENV with the environment variables the process inherited
Define an initial value for "current working directory" for use with relative file paths

What is Sapi Server in windows Phone 7

SAPI Server starts up whenever you use speech on Windows Phone, either via Voice Commands, Text To Speech, or direct Speech Recognition. (Yes, the links are to Windows Phone 8, but it's still true.)

Is there a reason I would use the Microsoft.Speech Namespace instead of directly using SAPI 5.4 in Visual Studio?

You might want to look at the answer to this question first.

Given that you're running on Windows Server, you almost certainly want Microsoft.Speech rather than System.Speech for the following reasons:

Server doesn't include any SR engines by default; you have to install the Desktop Experience pack;
System.Speech requires training to work well;
Microsoft.Speech has SR engines that work well with lower-quality audio.

You can still program directly to SAPI; the only real difference between Server SAPI and Desktop SAPI is the underlying SR engine. (The client-side API is exactly the same.)

Programming directly to SAPI is more complicated, but gives you more control. I couldn't recommend one or the other without knowing what your ultimate goals are.

What Is Sapi and When Would You Use It