Changes between Version 13 and Version 14 of soc/2007/cgi

Timestamp:

Feb 18, 2008, 6:25:29 PM (15 years ago)

Author:

Darren Garvey

Comment:

--

soc/2007/cgi

@@ -38 +38 @@
 }}}
 
-Protocols such as SCGI and FastCGI allow a single process to handle multiple requests. The simplest way to turn the above into an SCGI ''daemon'' is to use the synchronous API provided by the library. For example:
-
-{{{
-#!cpp
-#include <boost/cgi/scgi.hpp> // Include only SCGI functionality
-
-using namespace boost::scgi;
+Protocols such as SCGI and FastCGI allow a single process to handle multiple requests. The simplest way to turn the above into a FastCGI ''daemon'' is to use the synchronous API provided by the library. For example:
+
+{{{
+#!cpp
+#include <boost/cgi/fcgi.hpp> // Include only FastCGI functionality
+
+using namespace boost::fcgi;
 
 int main()
@@ -72 +72 @@
 Using a multiplexing protocol (SCGI or FastCGI) in a multi-threaded environment can be much more flexible than the example above allows. In many (if not most) cases you will be able to increase the throughput of your daemon by handling more than one request at a time (ie. within each process). To get the most out of your process you should use the asynchronous functionality of the library - kindly provided by Boost.Asio. Making a fully asynchronous program requires a different approach to synchronous ones and can be quite mind-bending until you are used to it.
 
-That said, you can still benefit from the asynchronous nature of the library without complicating your program by distinguishing between '''accepting''' requests and '''using''' them. For the example below, we can first create a Server, the purpose of which is to accept requests and pre-load the data from the clients (this is likely sub-optimal, but keeps the demonstration more to the point). The class shown is also not generic - it's only useable with FastCGI programs - but this is just to keep it concise. A generic version is provided (or should be soon) in the distribution.
+You can still benefit from the asynchronous nature of the library without complicating your program by distinguishing between '''accepting''' requests and '''using''' them. For the example below, we can first create a Server, the purpose of which is to accept requests and pre-load the data from the clients (this is likely sub-optimal, but keeps the demonstration more to the point). The class shown is also not generic - it's only useable with FastCGI programs - but this is just to keep it concise. A generic version is provided (or should be soon) in the distribution.
 
 {{{
@@ -191 +191 @@
 
 === ```cgi::response``` ===
-This simply holds headers and the content of the response and provides various ways to write to it. Up until it is sent to the user, it is unaware of what it's a response to. This helps keep code - both library and user code - clean and explicit, without being overly verbose and aids significantly with response caching (something this library won't address for now).
+This simply holds headers and the content of the response and provides various ways to write to it. Up until it is sent to the user, it is unaware of what it's a response to. This helps keep both library and user code clean and explicit, without being overly verbose and aids significantly with response caching (something this library won't address for now).
+
+''Use of this class is entirely optional.''
 
 === ```cgi::session``` ===
 This will provide simple session data caching. 
 
-=== ```cgi::basic_service<>``` ===
-This is the main class in the library. There should be specializations for each Protocol and the underlying structure should be generic enough to allow for any type of cgi-like protocol to be 'serviced', without sacrificing efficiency, clarity of code or any of the aims stated in the Design Notes.
+=== ```cgi::basic_protocol_service<>``` ===
+This is the base class in the library. It is a container for the `io_service`s (from Boost.Asio) that implement asynchronous support and holds lists of current connections and of waiting requests from multiplexed connections.
 
 == Important Internal Classes ==
 
-=== ```cgi::basic_gateway<>``` ===
+=== ```cgi::basic_client<>``` ===
 The gateway is the abstraction of the interface with the server. This can vary from just an abstraction of std::cin/cout to a fully multiplexed set of connections, which can themselves be of more than one type.