Boost logo

Boost :

From: Cory Nelson (phrosty_at_[hidden])
Date: 2007-04-05 17:26:45

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.

> *how should GET/POST variables be accessed? Like (perl) or python's
> cgi module?

I havn't used perl or python, but I think if you have a class
cgi_context, it should have get and post members. There is no limit
to post size (iirc) though, so a way to stream it might be useful to
keep memory usage down.

> *should cookie variables be accessible just like GET/POST vars, or
> separately? Should they be lumped together by default with more direct
> access when needed? Would it be confusing to allow user code to determine
> behaviour?

I think being able to access them like above for get vars would be a plus.

> *should the CGI environment variables each have explicit functions for their
> access, or should (eg.) a generic cgi::get_env() function be used?

Don't really have an opinion here.

> *url decoding functions are needed for GET/POST variables. Should url
> encoding functions also be provided?

Yes. Though not strictly CGI, I think a htmlencode/htmldecode might
be useful utility functions to include too.

> *how transparent should user code be to internationalization/different
> character sets?

You aren't always outputting text in CGI, so I don't think it should
be transparent. A way to access it as a text stream, perhaps with a
way to specify encoding, would be nice though.

> 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.
 Something I would also like to see is async support, with an API
similar to asio.

> Whether or not you see the point of a C++ CGI library, your comments on APIs
> provided by other languages would still be very much appreciated.
> Cheers,
> Darren
> _______________________________________________
> Unsubscribe & other changes:

Cory Nelson

Boost list run by bdawes at, gregod at, cpdaniel at, john at