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.
|
|
|
---
|
|
← [CppCMS 1.x.x tasks][prev]
|
| [Top](#maincontent)
|
| [Coding Standards for CppCMS 1.x.x][next] →
|
|
[prev]: /wikipp/en/page/cppcms_1x_tasks
|
[next]: /wikipp/en/page/cppcms_1x_coding_standards |
