Re: [boost] Fwd: [Boost-users][RFC] Preferred API for a CGI library proposal

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-05 20:07:47

Hi Cory,

On 05/04/07, Cory Nelson <phrosty_at_[hidden] > wrote:
>
> On 4/5/07, Darren Garvey <lists.drrngrvy_at_[hidden]> wrote:
> > [cc'ed from boost-users list]
> >
> > Hello all,
> >
> > This may seem off-topic, but I assure you it isn't. ;)
> >
> > This is an initial probe for ideas about an API for [any] upcoming CGI
> > library submission. Of particular interest:
> > *should GET/POST variables be parsed by default? (not _strictly_ API,
> but
> > relevant)
>
> Perhaps parsing them on first use might give a perf boost, but I don't
> think it would make much difference.

The other part to this question is with regards to the stdin stream (ie.
POST variables). This can be huge and there may be no need to parse it at
all. So, do you parse GET vars and not POST vars by default (possibly
breaking a program if there is a change of a form from GET to POST); parse
nothing (making code that bit uglier) or parse everything (potentially
dangerous)? Try a more complex way?

[noted, agreed, snipped]
>
> > The reason I'm asking such an open-ended question is that I'm assuming
> lots
> > of people here will have experience using CGI libraries (possibly in
> other
> > languages, possibly your own) and may have specific ideas about what
> should
> > or shouldn't move from them into a Boost.CGI library, if one were
> accepted.
>
> I think a CGI library should also include transparent FastCGI support.

I agree that shipping FastCGI support is a must - I'm not sure making it
completely transparent is the best option - but I agree in principle. This
discussion is for a separate thread though, perhaps (I've been thinking of
this for the summer of code (or just the summer...), so input is more than
welcome)?

Something I would also like to see is async support, with an API
> similar to asio.

By 'async support' you mean for input/output?

Thanks for the comments,
Darren