[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cgicc & FastCGI ...
From: |
Steve McAndrewSmith |
Subject: |
Cgicc & FastCGI ... |
Date: |
Sat, 23 Feb 2002 03:46:43 -0800 (PST) |
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.
==============================================================================
- Cgicc & FastCGI ...,
Steve McAndrewSmith <=