The CppCMS framework consists of following parts: |
|
## Long Living Classes |
|
- Central `service` --- the major class that holds |
the main application loop and manages all resources. |
|
All global resources are accessed via this service. |
|
It also hold the main event driven execution loop |
based on `boost::asio::io_service`. |
|
- `applications_pool` --- it the class that holds |
a pool of user created applications and dispatches |
them according to requested url. It is the major |
connector between URL and application. |
|
Each time the page is requested an application fetched |
from it and then returned back for recycling. |
|
- `thread_pool` --- is the thread pool for long running |
and time consuming jobs that can't be executed withing |
asynchronous event loop. |
|
Generally, when new request arrives it is executed |
by application in the `thread_pool`. |
|
- `locale::pool` --- is the gateway to i18n and l10n |
world. It holds the set of `std::locale` for each |
supported locale required by developer. It also |
adds custom facets like `gettext` in order to extend |
localization capabilities behind the strict set of |
facets provided by standard C++. |
|
- The configuration of all CppCMS components is done |
via single JSON object that is loaded by `service` |
and accessible via `json::object const &settings()` |
member function of `service` class. |
|
## Connection Related Classes |
|
When the main loop is started all incoming connections |
are accepted and processed by `impl::cgi::connection` class. |
|
This is an abstract class that various protocol connectors implement it. Currently CppCMS supports following protocols: |
|
- HTTP --- very simple and limited implementation of HTTP |
protocol that is used for debug purposes or for running |
CppCMS behind http-proxy. |
- FastCGI --- connector that implements standard FastCGI |
web server API and allows running CppCMS application |
behind any web server. |
- SCGI --- connector that implements standard simple |
and very useful SCGI protocol that is simpler equivalent |
of complex FastCGI. |
|
So, each time new connection is accepted it is read |
completely, including parsing headers and all POST data. |
|
When the connection becomes ready it is assigned |
to user visible `http::context` object that provides |
an interface for user to lower level CGI like protocol. |
|
When the `http::context` is ready, appropriate `application` |
is fetched from `applications_pool` and `http::context` |
object is assigned to it. |
|
When application finishes response, it releases |
`http::context` object that sends all the pending data |
to output and releases `cgi::impl::connection` for further |
reuse --- keep-alive requests. |
|
Then application is recycled to `applications_pool` for reuse. |
|
Other classes are used together with `http::context` |
|
- `http::request` --- it holds all POST data and request information. |
- `http::response` --- it used as gateway for writing back |
all data. |
- `locale::environment` --- access to all localization |
facilities for given request. |
|
Their lifetime is bounded to lifetime of `http::context` |
object. |
|
## Various Objects Lifetime |
|
All dynamically created and destroyed objects are reference-counted. Their lifetime is tightly bounded to their users. |
|
- `application` --- it is probably most complicated class |
in terms of its lifetime. |
|
When normal--synchronous application is fetched from |
the pool it receives a newly `http::context` and |
submitted to execution to the thread pool. When it |
completes the job, its reference counter goes to 0, |
and thus it is returned back to the pool releasing |
an `http::context` it owns. |
|
However, any application may submit pending |
asynchronous jobs to the main even loop and thus |
extend its lifetime when the main loop becomes its |
owner --- they exist all the time there is the |
pending job to do and they are recycled at the end. |
|
Another type of applications are long-running |
applications that are responsible providing Comet |
services. |
|
These applications are unique in the system and each |
time new `http::context` is created it assigned to |
specific long running application, thus it can |
hold many contexts simultaneously and respond on |
them any time it needs. |
|
Such application is generally owned by main event |
loop and it owns numerous connections. |
|
When all handlers to such application are destroyed, |
its reference counter goes to 0 and this application |
is destroyed. |
|
|
- `http::context` is owned by `application`. When |
application has no more jobs to to it releases the |
`http::context` that releases `impl::cgi::connection` |
it owns. |
|
This class is mostly proxy class between implementation |
specific connection and high level user API. |
|
- `impl::cgi::connection` derivatives are owned by |
the main even loop, until they are assigned to |
`http::context`. |
|
When `http::context` completes response to client |
it checks if the connection can be kept-alive and |
if so, returns it to the main loop for the next |
request. |
|
|
