[Fastcgipp-users] Started switching Fcgistream to boost::iostreams

[Eddie Carle]

I've started trying to transition the library over to boost::iostreams
which will allow us to solve the issues here. Unfortunately I'm running
into some road blocks. Below is a copy of the git commit message I've
put into a boostIostreams branch. I'm hoping somebody could offer some
insight. 

The switchover involves making the Fcgistream class a 
boost::iostreams::filtering_stream that has two "filters" in it. The 
first component will be the "Encoding" filter that will do any 
url/html/whatever encoding that needs to be done. Next in line is the 
boost::iostreams::device sink that takes buffered data and forms it into
FastCGI records sending it along it's way. When the Fcgistream has a 
parameter type of wchar_t, the device is encapsulated into a 
boost::iostreams::code_converter adaptor to do the utf-16/32 - utf-8 
code conversion. 

The transition is somewhat complete save a few roadblocks I've been 
running into with boost::iostreams::code_converter. I'm quite convinced 
that there may be some issues in the boost code which is why I'm keeping
this as a separate branch for now. Here is an itemization of the issues.
Note all of them only occur when the device is wrapped inside a
boost::iostreams::code_converter. Otherwise we are 100%. 

      * I cannot change the buffer size of the code_converter. There are
        parameters in it's constructor to allow for it but the buffer
        always seems to be 128 bytes no matter what I tell it. This is
        kind of a disaster for our purposes. 
      * I cannot for the life of me get the code_converter to flush its
        little buffer. I pass a strict_sync() to
        boost::iostreams::filtering_stream and every other component
        gets flushed save the code_converter. This issue actually makes
        it unusable because without being able to force flush the
        buffers the last bit of each request gets chopped off and isn't
        sent to the client.
      * For some reason, when I pass a buffer size to the code_converter
        (not that it does anything) it tries to copy construct the
        device not with a normal copy constructor, but some weird
        constructor that also takes a const long int& as a parameter.
        I've created a constructor that take said parameter and ignore
        it, but this is only a solution for testing purposes.
-- 
        Eddie Carle