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
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 CGI.pm (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
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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk