Actually, my point is more like the opposite. If all servers that support SCGI also support FCGI, there's no point in writing a client lib that supports SCGI because FCGI is faster (AFAIK) and will always be supported.
I misunderstood you, my mistake. Even though FCGI is inherently more efficient, given the simplicity in implementing an SCGI 'service' - in parallel to an FCGI and raw CGI one - and the current lack of complete FCGI support in apache, it still seems worthwhile. Plus, it's not beyond possibility that given small inputs and large outputs, on implementations that don't support multiplexing (apache, for instance, doesn't allow that), SCGI may just have an edge (a small one, admittedly). Essentially you're right, but if without SCGI, I may as well just implement an FCGI library that handles standard CGI, rather than a CGI library that handles FCGI, SCGI and any other potential protocols that map to CGI. If there's one thing Boost has taught me, it's that extensibility and flexibility are ace. :) Cheers, Darren