[cpp-netlib-devel] Nearly time to start merging?

[Darren G. <dar...@gm...>]

Hello all,

I've sent a couple of random messages to this list before regarding the
library under development and the CGI library I started working on for the
last GSoC. Because of the huge potential for shared code between the two
libraries I really hope we can find some common ground between our efforts,
seems silly not to. :)

The CGI library is now in a "mostly-works-but-is-really-ugly-in-places"
state - I'm blaming lack of time/practice for that! There are a couple of
reasonably major additions to be made when time allows (they're relevant,
see the postscript).

Anyway, there are some cool ideas in the netlib code. I especially like
using fusion::map<>s for holding request/response data and of course, the
common use of a basic_message<> class.

Perhaps we can open discussion about where things should and shouldn't align
and how best to do that? It'll be summer before I have any real time to
spend on this, but I'm really keen that we can make some progress on this.

Kind regards,
Darren

P.S.

Ideas:
* add a form_parser class (as part of the public API)
   - use Boost.Spirit
   - should read/parse multipart/form-data regardless of request type.
   - should allow incremental reading/parsing of individual form parts
* add a param class
   - holds a boost::iterator_range to the data
   - convertible to std::string subject to a macro condition (aka. taint
mode)
   - allows easy case-insensitive comparison (possibly using
Boost.String_algo? Or the netlib transform meta-functions?)
   - allows compile-time checking of its source (eg. env/GET/POST) to
protect against XSS vulnerabilities.
   - allows easy lexical casting (eg. param::as<>)

* add prepare/consume/commit member functions to network::basic_message<>
  - functions like in asio::streambuf.
  - would allow reading data straight from a (asio)(A)SyncReadStream (eg. a
socket), without need for buffering
  - could help with incremental parsing and/or making form_parser class
request-agnostic

P.P.S.

The basic_message<> class has embedded _source/_destination parameters.
These aren't particularly relevant to CGI/FastCGI/SCGI and they imply a
close relation between the payload of an HTTP message and its
source/destination, which might not always be a 1:1 relationship. I wonder
if they should be moved out of the basic_message<> class to some
higher-level abstraction?