RE: Cgicc & FastCGI ...

[Steve McAndrewSmith]

On Sat, 2 Mar 2002, Stephen F. Booth wrote:

> I hear what you're saying- it doesn't make sense to override the input
> and not override the output in most cases.  But I'm still resistant to
> the idea of the Cgicc class maintaining an output stream; I simply don't
> see it as a function of the class.

Dammit, now *I* see *your* point.  *sigh*.  Well, I don't suppose it really
matters, since I'm add a Qt wrapper class anyway, and I can implement what I
need there.

> Here's what I've done so far: I've implemented a simple class, CgiInput,
> that currently is a wrapper for stdin.read and getenv.  The constructor
> to Cgicc takes a pointer to an object of this type.  If the pointer is
> NULL, a library-owned static instance is used.  For users wishing to
> override the input source, they can pass Cgicc's constructor a subclass
> of this type.  I haven't yet implemented a wrapper for FastCGI- maybe
> you could help with this?  The CgiInput code has been committed to the
> CVS repository.

Sweet, thanks.  I'd be happy to implement a FastCGI instance (FCgiInput), and 
probably implement the output stuff there.

This is a really minor point, but I would implement the CgiInput passing 
differently:
  Cgicc( CgiInput Input = CgiInput() ) ...
  CgiEnvironment( CgiInput Input = CgiInput() )
  : Input( Input )
  { ... }

There's no need for a static CgiInput, instead the default value takes care of 
that.  You also take a negligable hit from the copy constructor - in the 
default case it's the same as passing a pointer, and in the FastCGI case it's 
two pointer copies.

I just offer this as an alternative way of getting the same behavior.  I don't 
know if it's any better, maybe I've just been doing to much stuff with 
Function Objects lately ...
 
> As far as output is concerned, my main issue is that I don't want to
> force users to use a customized stream class.  I do have an idea that I
> think is workable, though.

That's a great idea.  I would suggest, though, that you combin CgiInput and 
CgiOutput, something like:

  class CgiIO {
  public:
    virtual std::string read( int );
    virtual std::string env( std::string );

    virtual operator ostream &( void );  // standard output
    virtual ostream &err( void );        // error output

  protected:
    virtual int write( std::string );
    virtual int writeErr( std::string );
  }

The default implementation of read(), env(), write(), and writeErr() would
talk to stdio/environ (FastCGI would override these).  The default
implementation of the ostream operator and err() would be to return ostreams
thinked to write() and writeErr().  Cgicc/CgiEnvironment would *only* use
read() and env().  Since MStreamable's already can render to an ostream
(correct?), they could be piped directly to the instance of CgiIO that was
passed to Cgicc ... or not.

This is much the same idea I was suggesting before, except now the 
implementation of the ostream stuff would be in CgiIO, instead of Cgicc.  It's 
effectively what you're proposing, except that CgiInput and CgiOutput are 
combined into a single class, which also implements functionality for 
ostreams.  And it's all optional to the user.

What do you think?

==============================================================================
Steve McAndrewsmith                             Drummer / Hacker / Minor Deity
------------------------------------------------------------------------------
If Microsoft made your letter box, all some one would have to do is write
"Burn the house down" on a piece of paper and post it through the door,
and your house would go up in flames.
                                -- David Ruck
==============================================================================