Martin, On 19/08/07, Martin Wille <mw8329@yahoo.com.au > wrote:
Hmm, well the program has to bind to port 0, where connections are connected
to.
What? Port 0?
Hmm... Ok, they both bind to the stdin file descriptor (0). I've made this mistake before and obviously 'informed' myself with sketchy info. I'm very sorry for the (rotten) noise, but I'm glad my head's out of the sand (again, for now). Nasty. Anyway, a single program *can* indeed work with both protocols. This requires only a trivial addition to the interface and only minor changes internally. However, it does make the selective header/implicit typedef's strategy seem much more fickle. <snip>
Another scenario: imagine a closed-source FCGI/SCGI hybrid server. That server can't predict whether FCGI or SCGI will be supported better on the HTTP server that gets used by a customer.
Noted. Providing two different port numbers is much simpler than providing two versions of the program. One could also imagine SCGI or FCGI being used by programs that do not
happen to be a web server. (Supporting *CGI from the other side would be a nice addition to your library ;)
That's a large pool of use-cases that needs to be catered for, no doubt. Using a FastCGI daemon as an intermediate server/filter/load-balancer/etc. to other back-end processes is a very reasonable use-case, for example. Thanks for your persistence, Martin, that was no small brain-wrong you pointed out. :) Regards, Darren