On 3/9/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Darren Garvey wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful.
Yes, I think this would be a very useful library -- I have a homegrown one I've used in some personal apps. C++ developers want to program for the web as much as anyone else and the libs for C++ are, sadly, poor in comparison to other languages. Before focusing in on SCGI and FastCGI, what about support for plain old cgi request decoding and such? Would that be part of it?
Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC.
My worry is that the scope might be too large for SoC though. In any case, there might be a reasonable scope that could be carved out -- let's discuss it more :-)
Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
Is it really worth it? TCP sockets are pretty optimized by OS's at this point...
Yes, but usually UDS (and pipes that are often implemented on top of them) are still faster. Also sometimes you do not have a choice of the transport (think X-Windows over UDS) because it is dictated by some protocol spec. Also pipes support is useful if you want to participate in a shell pipeline. gpd