RE: Cgicc & FastCGI ...

[Stephen F. Booth]

> > I approach this (with my two-tiered library philosophy mentioned
above)
> as
> > two separate issues.  I can certainly see a strong argument to allow
the
> > user to specify where the input data should come from (POST/GET data
and
> > environment variables) but I'm not convinced that it should be
Cgicc's
> > responsibility for maintaining an output class.
> 
> I don't see why they're two different issues, even with the two-tiered
> philosophy.  This may be mangling your philosophy, but I see two
modules:
> "I/O" and "HTML".  As a practical example, consider that, if one must
> override
> the default functionality for input (to grab it from, say, an FCGI
> request),
> they're probably going to have to override output as well (there's a
> reason
> why "I/O" is a phrase - they go together).

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.  To me, Cgicc is a class that parses
the input data and provides it to the library user in an
easily-accessible and usable form.  What the user chooses to do with
this information is beyond the scope of the class.  But, I understand
now the need to be able to specify (in some fashion) an output
destination other than ostreams.  

> There's also the fact that it makes my life easier. ;-)  That is, if
you
> don't
> implement this, I (and everyone else who wants to run CGI/HTML over
> something
> other than stdio) are going to have to provide an ostream-to-whatever
> wrapper,
> to each application, for outputting stuff from the HTML module.  Since
> Cgicc
> already (or will soon) handle the whatever-to-istream and whatever-to-
> environment wrappers, why shouldn't it include output as well as input
> (and
> save us all some headache)?

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.

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.  I could create another class called
CgiOutput that would have a write(char *data, size_t len) virtual member
function.  I would add another pure virtual method to the MStreamable
class that would force subclasses to define operator<<(CgiOutput&
output).  In this way, library users could elect to use either the
CgiOutput class or standard ostreams (or fstreams or whatever) for
output.  In this way output would adapt an either/or philosophy as far
as which output method to use.  This would put some burden on you
because now you would be responsible for tracking both a Cgicc object
and an associated CgiOutput object, but that wouldn't be too difficult.
I see this as a way to keep my paradigm of separating form handling
capability from html output capability.  Anyway, let me know what you
think.

-Stephen