Cgicc & FastCGI ...

[Steve McAndrewSmith]

I'm trying to use Cgicc in a fairly complicated app, and I'd like to request
that "proper" FastCGI support be added.

Some background (in case anyone has any suggestions): the app needs to
maintain persistent state info that's shared by all requests.  The best
solution (that I know of) would be to use a static (i.e. single instance)  
FCGI program, which would spawn threads to handle requests, and maintain the
data structures (with appropriate locking).

In order to use Cgicc, however, I need to be able to do per-thread/-request
redirection of standard I/O and the environment from the FCGI request to
Cgicc.  While the newly added reader function pointer argument to
Cgicc/CgiEnvironment makes it possible to redirect standard input, it must go
through a global function which would have no (easy) way to determine which
thread/request was being serviced.  Since the environment is read through
getenv(), there's also no way to access the request-specific environment
(without a race condition).  Finally, it's assumed that the calling function
handles output, but that would require an ostream-to-FCGI_Stream wrapper.

I have a solution which I think can solve all three issues - function objects,
i.e.:

  class cgicc::IO {
  public:
    virtual int read( void *Data, int Length ) { ... }
    virtual int write( void *Data, int Lenght ) { ... }
    virtual string env( const string &Name ) { ... }
  };

I propose that Cgicc (and CgiEnvironment, in turn) use an instance of this
object for all I/O.  The default functionality would be to use stdio/getenv(),
and could be trivially overridden for use with FastCGI (or anything else).

As far as output goes, I suggest that it would be more correct (and more
useful, in these cases) to have Cgicc provide an ostream for outputting tags
and text, i.e.:

  class FastCGIIO : public cgicc::IO { ... }
  cgicc::Cgicc Req( FastCGIIO() );
  Req << h1( "Foo!" ) << getElement( "bar" ) << endl;

An ostream, either inherited or return from type-cast, would be called and in
turn call the appropriate functions in cgicc::IO.  This output design would be
completely compatible (and even interchangeable) with the current design.

Please let me know what you think about this.  I'd love to use Cgicc, but I
*have* to use FastCGI.  If necessary, I'll sit down and come up with a patch,
but I wanted to give you guys a chance to do it the Right Way[tm].

Thanks ...

==============================================================================
Steve McAndrewsmith                             Drummer / Hacker / Minor Deity
------------------------------------------------------------------------------
It is a miracle that curiosity survives formal education. 
==============================================================================