|
Boost : |
From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-03-10 07:36:49
>
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk