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. |
|
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.
|
|
|
