...
Threading abstraction
Non-XML-based configuration support
Logging abstraction
syslog
Windows event log
Apache error log
DDF (remoted data representation and serialization)
HTTP transport between agent and Java hub
Curl-based implementation
Windows-based implementation
HTTP Request/Responose abstraction
Session cache
Session abstraction
File-backed implementation
Chunked cookie implementation
Handler framework
Session initiator handler
Token consumer handler
Logout handlers
Other handlers
Portable authorization via RequestMap
Web server bridges to interface to requests and responses
Native modules
Apache 2.4 module
IIS module
FastCGI authorizer and requester
...
Unit Testing
The current code base provides a number of portability classes for abstracting POSIX and WIndoes threading APIs for threads, locking, condition variables etc. C++11 includes fairly complete APIs for all of that, with the exception of shared locking, which was added in C++14. That probably means leaving the code as is unless we move to C++14 as a baseline. OTOH, that’s a missed opportunity to get rid of some sensitive code.
Configuration Support
The current configuration is predominantly XML-based, supplemented/bridged to native Apache commands on that platform (none of the other current agents support a usable configuration mechanism).
The RequestMap will continue to be supported as XML, while other needs may be possible to address with a simpler format (JSON is not simpler and is much less flexble, but an INI or property file is definitely simpler). Boost has a somewhat odd-looking Property Tree module that appears to be header-only (so easy to use without adding runtime dependencies), and it actually supports reading and writing to INI, JSON, and XML(!) with some limitations in each case.
That may be a viable way to parse the RequestMap without delegating to Java, and in fact the representation is rather similar to what I built in Java using my DDF library. (The whole abstraction is somewhat similar to DDF in fact.)
For now, it suffices to say that we need to identify what the settings needed are and their general structure before settling on an approach, but this Boost option looks like a good fit simply due to flexibility(very lightly used) unit testing library is not great, and requires a Python-based processor. Boost has a unit testing framework inside it that can be used in both header-only and static/shared linking modes, and I’ve already done a bit with it enough to think it’s a good fit, particularly given the likely use of at least one other Boost library.
The plan is certainly to be much more extensive with tests so that much of the code can be run in isolation before connecting it to the Java and Web Server plug points on either side.
Threading Abstraction
The current code base provides a number of portability classes for abstracting POSIX and WIndoes threading APIs for threads, locking, condition variables etc. The main use of this code is around configuration reloads, and that’s valuable enough that it may still be worth doing. There are also some thread-local storage cases that may in some cases be hard to remove.
C++11 includes fairly complete APIs for all this, with the exception of shared locking, which was added in C++14. That probably means leaving the code as is unless we move to C++14 as a baseline. OTOH, that’s a missed opportunity to get rid of some sensitive code.
Configuration Support
The current configuration is predominantly XML-based, supplemented/bridged to native Apache commands on that platform (none of the other current agents support a usable configuration mechanism).
The RequestMap will continue to be supported as XML, while other needs may be possible to address with a simpler format (JSON is not simpler and is much less flexble, but an INI or property file is definitely simpler). Boost has a somewhat odd-looking Property Tree module that appears to be header-only (so easy to use without adding runtime dependencies), and it actually supports reading and writing to INI, JSON, and XML(!) with some limitations in each case.
That may be a viable way to parse the RequestMap without delegating to Java, and in fact the representation is rather similar to what I built in Java using my DDF library. (The whole abstraction is somewhat similar to DDF in fact.)
For now, it suffices to say that we need to identify what the settings needed are and their general structure before settling on an approach, but this Boost option looks like a good fit simply due to flexibility.
With respect to IIS, it does turn out the newer version supports a native XML configuration layer that’s extensible. It appears to be very complex to use, and my guess is we’ll be better off looking at that as a possible future direction to explore but probably not a great drop-in replacement for what we have now.
Logging
Currently we use a fork of an old C++ logging library. The elimination of dependencies and the fact that having out of band logging streams from within a web server has never worked well demands we drop this in favor of “native” options. Logging is of course non-portable, and some web servers do their own logging.
...