Boost logo

Boost :

From: Peter Simons (simons_at_[hidden])
Date: 2007-04-27 15:32:17

Hi guys,


In my humble opinion, the best design decision about libfastcgi
was the strict separation of protocol know-how and I/O code. The
library interprets memory buffers as input and produces memory
buffers as output. Because of this trait, it integrates nicely
with all kinds of I/O scheduling mechanisms, whether it is
blocking, non-blocking, or asynchronous I/O. I would hope that a
new and improved Boost.FastCGI library is implemented the same
way. It is tempting to go for tight integration with Boost.Asio,
for instance, but my recommendation is to avoid such a

libfastcgi is released under an all-permissive license. If the
code can be re-used in one way or another, I'd be all for it. I
guess, however, that implementing FastCGI from scratch is
ultimately easier than trying to get that rather old code up to

Best regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at