Among the individual Active FoxPro Pages components the AFP engine is the workhorse, as it were. When the engine is loaded it generates a named pipe. If it includes the debug option, it is named AFP3_QUEUE_DEBUG, without that option the name is AFP3_QUEUE. Following the remainder of the initialization, the examination of the license data etc. the engine assumes a waiting position and only wakes up whenever a request from the ISAPI extension has entered the pipe. In the DLL version the waiting time is interrupted every 500 milliseconds to find out if the AFP is to be shout down. The AFP in the EXE version has to additionally process Windows messages and therefore carries a heavier base load.

Whenever a request arrives it is read from the pipe and loaded onto the Request object. A File object is generated for the requested URL. The Response is also initialized. Subsequently, a loop is launched and only terminated if and when there are no further forwards initiated by Response.Call or Server.Transfer.

Through a chain of CCallFactory objects, a CCall object is determined at every loop cycle. That object is given the task of processing the requests. By default, this will be a CCallAFP object; you already know those as Document objects in the AFP page. The plug-in DirectCall installs its own CCall object. It processes requests differently from the customary AFP on principle. The CCall object is only responsible for the execution of the request.

In the case of CCallAFP, i.e. the "regular" AFP, the cache name is generated from the URL. If the corresponding program file exists, it will be executed. If not, the program file is generated, compiled and executed. This process fills the Response object.

If no further requests exist the Response object generates a valid HTTP response that is sent through the pipe to the ISAPI extension.