== !SessionAdapter == The implementation of a ```cgi::session```. '''Purpose''': Since the session 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. T should theoretically be generic, so could be boost::any (using this results in heap allocations, which might make it a poor default?). Maybe there should be a basic_session template which can be accessed directly to say how the data is held, and ```cgi::session``` is a ```typedef``` for a std::map container. '''Roadmap''': A shared-memory !SessionAdapter is going to be implemented over the summer (using Boost.Interprocess). The other types will be commented, although probably not tackled (note: the in-process memory adapter would be simple to implement, but it's not a priority as it not likely to be used much). == !CommonGatewayService == The service is the main class in the library, similar to ```asio::io_service```, and deriving from ```asio::io_service::service```. '''Purpose''': This is where the request queue is held, the thread pool is managed, any initialisation of the program is done and generally what library users interact with to do anything which isn't request-specific. Within the library, a request object initialises itself by calling ```basic_service<>::get_request()```, erases itself with ```basic_service<>::end(request&)``` and either interacts with the service, or the ```connection``` associated with the request. == !CommonGatewayRequest == The data from the client is stored in the request. Keeping transport data - eg. associated connection, destination ip, source ip - separate/enclosed seems logical. These could be held in a context<> construct, as an idea (the word comes from WSGI, although it's used in a slightly different context (NPI) there. == !CommonGatewayReply == Simply contains headers and a response string. It is returned to the client via a call to ```reply::send(request&)```. == Gateway == The gateway is the highest-level abstraction over the library-server interface. It manages accepting and closing connections for now. '''Roadmap''': gateway.hpp is basically 'complete' for now. If necessary (this is a very big if), the gateway could also be required to delegate writes to a free connection (ie. if the program has a multiplexing set of connections) or to open a connection with which to write the response. At the moment, I think the request should just hold a pointer to the connection associated with it and write directly to that. Rather than having the request/response write to the gateway, the connection could try sending the response, and if for any reason it can't, then it sends the response on to the gateway for handling. == Connection == A Connection is the interface with the server (or outside world). It can be a pipe, a socket or just a cin/cout wrapper. '''Provides''': read(), write(), async_read(), async_write(), maybe more (like read_some(), write_some()). '''Roadmap''': A TCP socket is required for FastCGI and SCGI protocols and a std::cin/cout wrapper is required for standard cgi. Pipe support will follow support for that in asio (I don't know how that's going to work ATM). File i/o support would be nice too. In other words, a stock set of requests could be taken from files and responses written to files: this would be very useful for testing purposes. == Protocol == '''Alternatives''': cgi, fcgi, scgi, http, etc. '''Roadmap''': Implement everything for cgi and fcgi protocols. scgi SHOULD be implemented, just as long as it doesn't stop the project from being completed. == Dispatcher == A dispatcher receives events from the library and must act on them. It is agreed that it should be decoupled from the library core, but the details of the decoupling are still fuzzy.