Changes between Version 10 and Version 11 of soc/2007/cgi

Timestamp:

Jun 6, 2007, 1:16:47 AM (15 years ago)

Author:

Darren Garvey

Comment:

--

soc/2007/cgi

@@ -19 +19 @@
 {
   cgi::request req;   // set up the request
-  cgi::response resp; // see Design Ideas for more about this
+  cgi::reply rep; // see Design Ideas for more about this
 
-  resp<< "Hello, " << req.param<cgi::GET>("user_name") << "!";
-  resp.send(req);
+  rep<< "Hello, " << req.param<cgi::GET>("user_name") << "!";
+  rep.send(req);
   
   return 0;
@@ -32 +32 @@
 int sub_main(cgi::request req)
 {
-  cgi::response resp; // see Design Notes for more about this
+  cgi::reply rep; // see Design Notes for more about this
 
-  resp<< "Hello, " << req.param<cgi::POST>("user_name") << "!";
-  resp.send(req);
+  rep<< "Hello, " << req.param<cgi::POST>("user_name") << "!";
+  rep.send(req);
 
   return 0;
@@ -58 +58 @@
 See [wiki:soc/2007/cgi/Concepts Concepts] for more.
 
-'''Separation of ```cgi::request``` and ```cgi::response```''':
+'''Separation of ```cgi::request``` and ```cgi::reply```''':
 
-This separation is only a recent change. The main reasoning is that meta-data exists for both the request and the response. Using getters/setters is one idea, although in a large program, there could be a situation where you set a response header and then need to check it later. If everything was done with the ```request``` object then there'd be no way to achieve this.
+This separation is only a recent change. The main reasoning is that equivalent meta-data exists for both the request and the reply (ie. same identifier, different value). Using getters/setters is one idea, although in a large program, there could be a situation where you set a response header and then need to check it later. If everything was done with the ```request``` object then there'd be no clean way to achieve this.
 
 Having two objects has other advantages:
  * Code is clearer, without being too verbose
- * Response caching is easier to implement; code can just cache a ```cgi::response``` since it holds no data relevant to the specific request (note: response caching isn't really part of this project, although ```cgi::session``` will probably provide basic facilities)
+ * Response caching is easier to implement; code can just cache a ```cgi::reply``` since it holds no data relevant to the specific request (note: response caching isn't really part of this project, although ```cgi::session``` will probably provide basic facilities)
 
 '''Having the !CommonGatewayService control threading'''
 
- * In order for the program initialisation time (ie. the time before the first request begins to be handled) to be kept to a minimum, pre-emptive multithreading is not an option.
- * Users shouldn't have to implement complex event handling mechanisms in order to write a responsive, multiplexed application.
- * Since CGI request handlers can take a long time to complete, having i/o and request handling done in the same threads can cause starvation of i/o. Giving a guarantee that handlers will only be called in threads calling ```basic_service<>::run()``` might cause this and other problems.[[BR]]
- Options:
-  1. There should be threads calling ```basic_service<>::run()``` which handle input and output, and a separate set of threads which run the request handler provided by the user.
-  2. Only threads calling ```basic_service<>::run()``` should handle requests, but the service should be able to increase the number of threads calling run().
-  3. If a user really wants all to be handled in the same threads, then passing a boost::thread_group to the service's constructor could provide a compromise: the user uses the thread_group to call ```basic_service<>::run()``` and the service uses it to dispatch request handlers.
- * As a consequence of the above points, the number of running threads should be variable. Without this would lead to unresponsive programs if the user wasn't using a Proactive (ie. asynchronous) model or didn't have a good way of monitoring the service and adapting the number of threads.
- * When threading support isn't available, a FastCGI application (for instance) should still 'just work', with request handlers running concurrently instead of in parallel.
-
-'''Thread-pool vs. thread-per-request'''
-
- ''Note: Since each connection can be multiplexing, it doesn't make sense to allow a thread-per-connection policy as this would make request response times inconsistent.''
-
-In general a thread pool will be more efficient than having a thread per request, especially if the reply is no more than a true/false statement (eg. in the Authorizer FastCGI role). A thread-per-request option should exist since thread local storage would be compromised using a thread pooling strategy, making an application less secure.
-
-'''Single-threaded application'''
-
-In the case of threading support not being available, all services should still work. Also, the style of the first example (above) should map to a FastCGI application by simply creating an ```fcgi_service``` first and then passing that to the ```cgi::request```'s constructor.
+See [wiki:soc/2007/cgi/Dispatching Dispatching].
 
 == Main Classes ==