On 09/03/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?
Of course. :) The idea would be to use a cgi::request object, which you could pass a 'service' object to: the service object deals with the protocol and then the resulting cgi-shaped request can be transparently accessed through the request object.
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 :-)
Well I've been having a go implementing the fastcgi protocol using asio and even though it's not finished, I believe given some dedicated time I could have it fully working. SCGI is supposed to be 'simple' - and seems to be - so that shouldn't be too big a deal to add: either way, that is something that could follow, I suppose? Then there's the docs of course. Forgoing any major oversight on my part, from what I understand so far, I think it is doable in 2-3 months.
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...
It probably isn't, although I honestly don't know. Thankfully it won't really matter since servers should be able to run fastcgi apps via tcp anyway (apache and lighttpd do). Using UDS/pipes is purely an optimisation. Jef
Thanks for the reply, Darren