|
Boost : |
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-03-09 09:58:17
On 3/9/07, Jeff Garland <jeff_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk