On 4/5/07, Darren Garvey <lists.drrngrvy@googlemail.com> 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 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 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: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org