Changes between Version 2 and Version 3 of soc/2007/cgi
- Timestamp:
- May 25, 2007, 1:55:07 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
soc/2007/cgi
v2 v3 2 2 3 3 Below is a partial list of things this project aims to provide: 4 * Simple access to standard CGI environment variables and input data 5 * Clean access to request meta-data (ie. 'environment vars') and input data using alternative protocols, such as FastCGI 6 * Asynchronous read/write support 7 * A clean way to write to clients without knowledge of the underlying protocol in use 4 * Simple access to standard CGI environment variables and input data. 5 * Clean access to request meta-data (ie. 'environment vars') and input data using alternative protocols, such as FastCGI. 6 * Asynchronous read/write support. 7 * A clean way to write to clients without knowledge of the underlying protocol in use. 8 * Minimal process initialisation time: most of the time, clients will be handled by multiple process images, so each time one is started up, there can't be a noticeable load-time before handling the first request. 9 * Basic session support: by default Boost.Interprocess will be used for saving the memory, although the SessionAdapter concept should allow for other saving methods to be added later (such as files, databases or in-process memory). 10 * Internationalisation support should be considered, although to what extent this can be tackled I'm not yet sure. 8 11 9 12 == Usage == … … 30 33 cgi::response resp; // see Design Notes for more about this 31 34 32 resp<< "Hello, " << req.param<cgi:: GET>("user_name") << "!";35 resp<< "Hello, " << req.param<cgi::POST>("user_name") << "!"; 33 36 resp.send(req); 34 37 … … 60 63 * 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) 61 64 65 '''Having ``cgi::service`` control threading''' 66 67 62 68 63 69 == Main Classes == … … 80 86 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. 81 87 88 == Important Internal Classes == 82 89 83 84 Since the cache could reside in process memory, shared memory, files or a database, the class should be flexible. The actual data will be held in a ```std::map<std::string, T>```. T should theoretically be generic, so could be ```boost::any``` - this 90 === ```cgi::gateway<>``` === 91 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.