Quote Originally Posted by jpbro View Post
FastCGI is designed to support long-lived application processes, i.e. application servers. That's a major difference compared with conventional Unix implementations of CGI/1.1, which construct an application process, use it respond to one request, and have it exit.

My initial reading of the above lead me to believe that what I was creating an application server which I guess I shortened to just server or FCGI server, perhaps wrongly in terms of clarity.
At a certain point words like server and client can get confusing because they describe roles, and any given bit of running code can have more than one role at the same time.

But it sounds like what you are making is an interface API: code to help a VB6 "application server" communicate with a FastCGI web server.


All of that is less interesting to me than the reasons or possible use cases for ever doing any of this. Why would anyone want to? Is this just a matter of showing how it can be done? Because I don't see any practical use for it today.

If a VB6 application needs to be able to respond to HTTP requests you can just write the code inline or use a 3rd party component. Such programs can't really use FastCGI, because in that relationship they need to be under the thumb of the FastCGI web server and shouldn't have a visible user interface at all. Normally such a server starts and stops such programs as needed.

I can live with "just because" as a reason, but as I said I can't imagine anyone using it as part of a practical solution to anything.