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

From: Cory Nelson (phrosty_at_[hidden])
Date: 2007-04-06 03:35:10

On 4/5/07, Darren Garvey <lists.drrngrvy_at_[hidden]> wrote:
> 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?

I think GET should be parsed immediately, and POST should be read in
by the user.  Maybe have an adapter class that can decode POST data if
the user wants it like that?

> [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)?

Well, normal CGI is already phased out by scripting langs, I imagine
FastCGI will be the primary use of this library.  Innards can be kept
to other threads but I think not taking it into consideration while
discussing the basics of the library would be a mistake.

I do think it could be mostly transparent: the user should be able to
setup a request handler and either give it to a FastCGI listener or
attach it to stdin/stdout without code changes.

> Something I would also like to see is async support, with an API
> > similar to asio.
>
>
> By 'async support' you mean for input/output?

Yes, like an asio socket class, with begin_read/begin_write etc.

This is one thing I always see lacking in current web development
kits: so many of them spend time accessing databases etc, things that
block and should be done in an async manner, and I bet suffer
performance because of it.  It would be nice for a change to have an
API that allows such scalability when it is wanted and ease of use
when it doesn't matter.

This is not so important for regular CGI but in FastCGI it could be a
great boon.

> Thanks for the comments,
> Darren
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Cory Nelson
http://www.int64.org