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

Timestamp:

May 22, 2008, 4:05:39 PM (14 years ago)

Author:

Darren Garvey

Comment:

Removing some glaring errors.

soc/2007/cgi

@@ -1 +1 @@
 == About ==
+
+: Warning: This page may be out of date, see http://cgi.sf.net/doc for more up-to-date documentation.
 
 Below is a partial list of things this project aims to provide:
@@ -28 +30 @@
   response resp; // make an empty response
 
-  std::string name(req.GET("user_name"));
+  std::string name(req[get]["user_name"]);
   resp<< "Hello there, "
       << (name.empty()? "stranger" : name)
       << "!";
-  resp.send(req.client());
-  
-  return 0;
+
+  return_(resp, req, 0); // send the response and `return 0;'
 }
 }}}
@@ -57 +58 @@
   while(a.accept(req) == 0) // no error here
   {
-    std::string name(req.GET("user_name"));
+    std::string name(req[get]["user_name"]);
     resp<< "Hello there, "
         << (name.empty()? "stranger" : name)
         << "!";
+
     resp.send(req.client());
-    req.close(http::ok);
-    resp.clear();
+    req.close(http::ok); // note: we can reuse the old request's memory now
+    resp.clear();        // note: we can reuse the old response's memory now
   }
 
@@ -140 +142 @@
 
   resp<< "Hello, "
-      << req.form("user_name") // this accepts either GET or POST variables.
+      << req[form]["user_name"] // this checks either GET or POST variables.
       << "!";
-  resp.send(req.client());
-
-  return req.close(http::ok); // we have to explicitly close the requests now.
+  
+  return_(resp, req, 0);
 }
 
@@ -170 +171 @@
 '''Separation of ```cgi::request``` and ```cgi::response```''':
 
-This separation is only a recent change. The main reasoning is that equivalent meta-data exists for both the request and the response (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.
+The original reasoning for this is that equivalent meta-data exists for both the request and the response (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:
@@ -182 +183 @@
 == Main Classes ==
 
-=== ```cgi::basic_request<>``` ===
-This holds the data corresponding to the request. It will be specific to a Protocol type and will be aware of how to receive, send and parse data for that Protocol. There will be ```typedef```s for typical usage.
-
-=== ```cgi::request``` ===
-By default, this provides a general (as opposed to generic) access point to any type of request. If constructed with a service object, then the request takes a request from the queue (or blocks until one is available). Default construction initialises a standard cgi environment.
-
-This generality is achieved using runtime linkage in a similar way to boost::any, although static linking can be forced using a choice of macros which turn ```cgi::request``` into a ```typedef``` for a particular ```cgi::basic_request<>```.
-
-=== ```cgi::response``` ===
+=== ```cgi::common::basic_request<>``` ===
+This holds the data corresponding to the request. It will be specific to a Protocol type and will be aware of how to receive, send and parse data for that Protocol. There will be ```typedef```s for typical usage. (ie. ```cgi::request, acgi::request, fcgi::request```).
+
+=== ```cgi::common::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 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).
 
@@ -196 +192 @@
 
 === ```cgi::session``` ===
-This will provide simple session data caching. 
-
-=== ```cgi::basic_protocol_service<>``` ===
+
+This will provide simple session data caching. NOT YET!
+
+=== ```cgi::common::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_client<>``` ===
+=== ```cgi::common::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.
 
-=== ```cgi::basic_request_acceptor<>``` ===
+=== ```cgi::common::basic_request_acceptor<>``` ===
 Accepts a new, possibly unloaded request. Before using the request `cgi::basic_request<>::load()` or `cgi::basic_request<>::async_load()` '''must''' be called.