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

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 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