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 dependency. 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 speed. Best regards, Peter