Well, not exactly. CGI basically, and in the classic sense, starts a .EXE process with every hit. The big improvement came with ISAPI, a replacement to CGI, which is a .DLL instead of a .Exe and offers a tremendous improvement in performance and scalability. An ISAPI extension actually becomes a part of IIS. So, Foxisapi is part of this ISAPI tradition, not CGI at all. ASP and ASP.NET are implemented as ISAPI extensions as well and are also very fast. They also represent MS flagship products so you can depend on them to be highly optimized, reliable, and as tightly integrated with the OS and IIS as possible(making implementation easy). So any way you implement this you will have an ISAPI extension and some kind of VFP server. A solution with foxisapi therefore is not simplifying anything (some might argue it makes your solution more complicated).
On the server side with VFP we have a similar evolution. It never made sense to start VFP with each web hit, even when it was a CGI Query server(the VFP web Query Server was single-threaded and launched from a C++ .exe, thus making it a CGI app). So with VFP, there have always been servers running n the background servicing web requests. The communication between C++ ISAPI and VFP server has ranged from passing text files (slowest and least scalable) to using DDE, named pipes, or COM all of which are fast because they use memory to exchange web information. The traditional brute-force way to allow multiple web requests to be processed simultaneously with VFP has been to run 3 or 4 VFP EXEs in the background waiting to service web requests. This is only a simulation of multi-threading and highly inefficient since the runtime is loaded with each instance and a large number of users is likely to overwhelm the 3-4 vfp .EXE servers. The big improvement came with VFP mtdlls which start a new thread (or re-use a previously used thread) with each hit. This is true multi-threading and highly efficient since it uses the smaller vfp?t.dll runtime and it is shared among threads instead of being loaded with each instance.

>>Foxpro CGI??
>That's what foxISAPI is (i think - but am often wrong:). The result of a post or get is written to an INI file on the "server" with names like "FOX1C.INI". IIS provides foxISAPI with a "session" id. CGI-COM then reads the contents of the INI file (i used to use FOPEN() a million years ago). Now file_to_string will do it. CGI_COM then assesses the contents and routes a reaction (return script). I think there's a guy called "GetProfile" - that also faciltates a read of the "post" data.
>
>I think that kind of transaction is CGI.
>
>Its clumsy - I just read some stuff in IIS help about ASP. YOU GUYS ARE RIGHT. It seems that ASP will contain the form results and [can] also instanciate my VFP "logic" COM. Which of course will get be out of the CGI-COM business and allow me more time for the "logic" guy.
>
>But the client - and they host a bunch of servers and even use WC for some of their services - asked that I keep it as lean as possible. The only "technical" requirement (from the regulating/advisory body) is that the client (browser) be JS and Flash enabled.
>
>So the client is a geek too! And I sugessted ASP (more than once) - and their response was that some of their users do not have ASP installed on their servers. And - that they would prefer not to have ASP as a requirement. With foxISAPI - only the CGI COMs would have to be registered.
>
>You sounded surprised about the CGI "label". Is there a "store" for post data on the server that would eliminate my need to read INI files? The INI file is the only store I am aware of. And, INI file = CGI (or so i believe)!
>
>You guys are correct - but despite my pleas, the marching orders remain the same:(.
>
>This is not so much a database project as it a "DOM" project. When you have time check out "Shared Content Objects". The protocal and source is a mountain of JS,JSP and JAVA as well as PDFs - some with hundred of pages of edit change bibliographies (YUKOLA!). Is this what my life has come to - an operations researcher that can [also] write code?:) Life was a lot easier when I only had DBFs and indexes to contend with!