## Create Backward Compatible ABI for CppCMS |
|
Make CppCMS having backward compatible ABI as Qt. Meaning: |
|
- Use local version of Boost that does not export symbols |
- Remove Boost from API! It should never be visible for user. |
- Remove dependecies on: CgiCC, fastcgi++, ICU. |
|
## CppCMS core components refactoring |
|
- Removal of dependency on CgiCC -- today there is about 5% of CgiCC library |
is used, many features are not supported by it or are not supported well. |
For example: file upload handling in CgiCC is very primitive, limited |
and error prone, support of cookies buggy and so on. |
- Using of Boost.Asio as internal event handler, because: |
1. It provides transparent synchronous and asynchronous event handling |
allowing future implementation of server push technologies. |
2. It provides efficient timer based event handling. |
- Removal dependency of libfcgi and writing Boost.Asio friendly |
implementation of FastCGI/SCGI connectors. Implementation of HTTP |
connectors as well. |
- Support of plug-in applications in CppCMS framework. |
- Improving compilation speed by representing more `pimpl` idioms and |
removal of unnecessary classes. |
|
## Better support of i18n and and l10n: |
- Transparent support of `std::wstring` with forms including automatic |
encoding testing and conversion. |
- Support of `std::locale` for localization for outputs like numbers, |
dates, monetary, translation and so on. |
- Optional support of ICU and icu::UnicodeString and icu::Locale that |
would add unsupported features by `std::locale` and allow replacement |
`std::locale` features with more correct implementations provided |
by ICU. |
|
## Remove libmm |
|
OSSP mm is licensed under 4 clause BSD license that is |
not compatible with GPL. It should be replaced with |
Boost.Interprocess that is available starting from 1.35 |
and have anonymous map for forked processes starting from |
1.36. |
|
## Improve Widgets |
|
- Improve widgets to cover _all_ options available in |
standard (X)HTML |
- Support of charset validation |
- Support of properties in templates. |
|
## Documentation |
|
### Terminology |
|
Line Up Everything with consistent terminology --- don't mix view/skin/template etc. |
|
### Internals |
|
All internal features should be documented in order |
to allow transparent extension of various features. |
|
## Improve Cache system |
|
Today cache system uses: |
|
- std::map as primary and secondary key |
- Implements additional secondary key for explicit removal |
based on timeouts. |
- LRU algorithm for cache |
|
This solution works with O(log n) complexity and not scan |
resistant. |
|
Following Required: |
|
- Remove timeout index in order to remove log complexity. |
- Replaces key/value search container of std::map to `unordered_map` in order to achieve O(1) complexity. |
- Test possibility of replacement of LRU algorithm with 2Q that is scan resistant algorithm. (Is this relevant for Web?) |
|
## Improve TCP Cache |
|
Problem: |
|
Today distributed cache system works very similarly to memcached --- every fetch requires round-trip to remote server. This significantly reduces cache performance in case |
of distributed system in comparison to in-memroy cache. |
|
Thus in the process of scale-up performance/cost factor becomes much lower when use of distributed cache is started. |
|
Solution: |
|
Implement L1-in-memory cache that would cache most frequently used cached entries in memory of each of the nodes of distributed system. |
|
How to manage consistency of such cache? Probably the size of L1 cache should be quite small and it should not be updated frequently. Cache servers should be aware of entries stored in L1 cache and thus broadcast "rises" only for cached keys --- this would remove all unnecessary traffic of removed entries. |
|
## Cache Debugging utilities |
|
Problem: |
|
Debugging of application that uses trigger based cache can be quite painful due to problematic access to internal structures of cache system |
|
Solution: |
|
Implement simple CppCMS application that would create a browser based access to cache content. |
|
## Degraded Mode of work |
|
Problem: |
|
What happens when one of cache/session servers fails? |
|
Solution: |
|
Provide automatic servers fail-detection procedures and continue to work in degraded mode. |
|
## Logging |
|
Provide simple logging framework for CppCMS applications |
|
## XSS Filters |
|
Provide some efficient anti-XSS filters. It is very important part of web development but there is no tools written in C/C++ that does this. |
|
## CppCMS as apache loadable module |
|
Test Feasibility of Running CppCMS application as |
apache loadable module should be tested. |
|
Questions: |
|
1. How several different application would interfere? |
2. How to implement separation interference in process shared cache and in templates system. |
3. Is this required at all? |
|
## Native Windows Support |
|
- Consider how much effort should be put to make CppCMS support windows naively |
- Consider how much effort should be put to make CppCMS support windows natively |
- How degraded this mode would be? |
- Is it feasible to do only withing Mingw environment or VS may be applicable as well? |
|
|
