Main  /  Edit version 10  /  Edit version 11  /   /  Users Area

Difference "Internals of CppCMS 1.x.x" ver. 10 versus ver. 11

Content:

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.

Sidebar:

← [CppCMS 1.x.x tasks](http://cppcms.com/wikipp/en/page/cppcms_1x_tasks)
[Coding Standards for CppCMS 1.x.x](http://cppcms.com/wikipp/en/page/cppcms_1x_coding_standards)→

About

CppCMS is a web development framework for performance demanding applications.

Support This Project

SourceForge.net Logo

Поддержать проект

CppCMS needs You


Navigation

Main Page


Valid CSS | Valid XHTML 1.0