Future Development

Iostream functionality.

Streamed IO, likely to be similar to Boost.Asio's basic_socket_stream<> is required.

SCGI support.

I haven't managed to get apache/lighttpd configured properly for SCGI, so this isn't functional yet.

FastCGI support is essential to any modern CGI library. There is currently no known FastCGI library for C or C++ that aims to implement the complete FastCGI 1.0 specification. Providing support for multiplexing FastCGI daemons is one of this library's major goals.

There are a couple of issues that have yet to be worked out, but FastCGI is working in a basic way now.

Access to error output streams

CGI, SCGI and FastCGI all make provisions for some sort of error outputting, according to the following table:

Protocol	Native error reporting capabilities
CGI	Single error output stream (`std::cerr`)
SCGI	A single output stream (`std::cerr`) is shared between requests: Boost.CGI will guarantee thread-safe access to it.
FastCGI	Error stream per request. Inherently thread-safe.

Even though the server is not obliged to do anything with this output, it is generally dumped into the default server error log. This can be invaluable for debugging.

Access to the above streams will be implemented as a Service, which can be switched on or off at runtime. Output can be sent either to stdout, stderr, or both simultaneously. If this isn't enough, a user can add their own custom service layer, which can manipulate the data as it is read/written in any way they wish (such as logging to a database, url-encoding/filtering data, or playing an April Fool's prank on your website visitors).

Session handling.

Access to persistent session data is a very useful stop-gap to using a complete RDBMS to store/retrieve data. In some cases, such as when an object is supposed to stay in active memory, a RDBMS will not be efficient, so session management fits in nicely. A templated basic_session<> will be provided so various session-storage methods can be used. Boost.Interprocess is an ideal default, while Boost.UUID can be used to generate unique session identifiers.

Having request variable functions return a `cgi::param` type instead of `std::string`

An advantage to this approach, for the functions that look up request data, is that multiple values can be easily extracted from the same key, when they exist. Currently, a user must get the complete map of data and use that themselves.

Another advantage is that a macro can be provided to turn on/off implicit conversion to std::string, which is in essence a form of tainting, akin to perl's taint mode.

Yet another possibility, is that a member function as<> can be provided as a shortcut to boost::lexical_cast<>. This could greatly improve readability of web programs, where lexical casting is very common and may make programs overly verbose.

Compare:

cgi::request req;
cgi::response resp;

cgi::map::const_iterator iter = req.form().find("number");
if (iter != cgi::map::const_iterator())
{
  rep<< "You picked no numbers...";
}
else
{
  int sum(0);
  resp<< "Your numbers are: ";
  for(; iter != cgi::map::const_iterator(); ++iter)
  {
    resp<< iter->second << " ";
    sum +=  boost::lexical_cast<int>(iter->second);
  }

  resp<< std::endl
      << "Your numbers add up to: " << sum;
}

rep.send(req);

to:

cgi::request req;
cgi::response resp;

cgi::param p = req.form("number");
if (p.empty())
{
  resp<< "You picked no numbers...";
}
else
{
  int sum(0);
  for(; p != p.end(); ++p)
  {
    resp<< p << " ";
    sum += p.as<int>());
  }

  resp<< std::endl
      << "Your numbers add up to: " << sum;
}

resp.send(req);