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
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