There has been a discussion concerning SCGI and also a question about FastCGI on the mailing list, but AFAIK without a definite conclusion.

If it is difficult to implement for some reason, please add a notice into FAQ or somewhere else in the documentation. Thanks.

stephan added on 2011-09-14 18:13:47 UTC:
Just some random notes:

- FastCGI requires the global use of FastCGI drop-in replacements for read/write calls. ALL code using the fread/fwrite/and friends APIs must use the FastCGI replacements.

- The FastCGI wrapper for fwrite() has a broken type signature, possibly requiring a kludge in the client code:

# define FWRITE(p, s, n, f) FCGI_fwrite((void *)p, s, n, f)

FCGI_fwrite() is defined to take a _non-const_ pointer as the src memory address, which is incompatible with fwrite() and breaks code which references fwrite via function pointer.

Additionally, FastCGI requires per-app-run state, which fossil's architecture cannot handle (it makes heavy use of global state). That said, DRH once suggested the fork()ing each instance as a workaround. The cost of fork()ing _might_, however, be as high as _not_ using FastCGI.

lrem added on 2011-11-19 13:32:54 UTC:
Apart from being somewhat intrusive, usage of FastCGI devkit would require its authors to submit the copyright releases (which, I don't know why, I feel to be unlikely).

While I've always been happy with FastCGI, I don't feel it's actually needed for Fossil. It seems to be efficient enough to use a proxy pass to a standalone Fossil server.

drh added on 2011-11-25 15:31:22 UTC:
A reasonable implementation of FastCGI for Fossil would be:

1. Capture the FastCGI parameters and query content
2. Write the query parameters and content into a temporary file formatted as a normal HTTP request
3. Use fossil_system() to recursively invoke Fossil to process the generated HTTP request, writing the results into another temporary file.
4. Read back the reply out of the second temporary file
5. Reformat and send the reply back to the FastCGI requestor
6. Delete the two temporary files.

The above is basically the procedure used to implement the "ui" and "server" commands for windows, as shown in the win32_process_one_http_request() function in the winhttp.c source file. The main difference is that in the case of the "ui" and "server" commands, the incoming request is already a valid HTTP request and does not need to be translated as it is moved in and out of the temporary files. So, in other words, a Fossil FastCGI implementation would basically be the same as the windows ui/server implementation with some extra coding and decoding logic thrown in.

Note that the above implementation is completely isolated and does not require any changes to any existing parts of Fossil. One has merely to add a new "fastcgi.c" source file that implements the above. All of the FastCGI decoding and translation and protocol handling would be contained entirely in that one source file.

I think the only reason for wanting to support FastCGI is so that you can run Fossil more easily using nginx. FastCGI won't be any more efficient. In fact, if you consider the extra encoding and decoding logic that has to run, FastCGI will probably be less efficient than simply configuring nginx to relay requests to a running Fossil "server" instance.

jeremy_c added on 2011-11-26 15:45:25 UTC:
I think the SCGI may be a viable alternative as well? SCGI as of the last few years has gained much popularity while FastCGI seems to have dwindled in popularity. SCGI is a simpler protocol and from my experience has more web server support than FastCGI.