1. The dynamic interface unsuprisingly lends itself to having a compiled library for the library functions. At this early stage I'm tempted to make "compiled" the default choice - ie. using the dynamic portion of the library would simply mean including some declaration-only headers and having everything else hidden in a single library. This would mean very fast compiles and small application binaries.
This is very good point to start from ;-)
I don't see at the moment why the .cpp files couldn't actually be .ipp files that could optionally be included in the headers to prevent the need to link against a CGI library.
Yes this very good idea.
2. The dynamic interface seems to lend itself to a really simple Python binding. I'm not convinced there is any point in going very far down this route as Python is awash with CGI libraries and WSGI seems to be the de-facto standard anyway. Still, Python's FastCGI support is based on the standard FastCGI library so there might be some room for gains.
Thoughts?
I think that python programmers would like to use asynchronous FastCGI interface they would rather prefer to have it over Twisted event loop rather over Boost.Asio. Also the standard fastcgi library is very good and well proven one, not talking about the fact that WCGI is available in any Python. so I don't think it would be useful for synchronous operations.