HotRod C++ Native Client 8 Series
The Infinispan Team started the development of the new HotRod C Client (version 8) with two main goals in mind: update and refresh the code and reduce the feature gap between the C client and its Java big brother.
The work is still in progress, but since we’re close to the 8.0.0.Final release, I would like to describe, in this and in the following posts, what’s changed as of today.
Although there are a lot of changes and improvements in the code (protocol updates, segments topology, configurable balancing strategy… you can have a detailed view of the activities stream browsing to the Jira issues), I would like to focus on the following three big changes:
Activities grouped under this title are motivated by the change in the development approach of the new features. Until version 7 we have followed the approach of keeping the baseline compiler requirements quite low to ensure a broad client portability, even to platforms with old compilers/libraries, #[#result_box]#but when we started development for the 8 series we felt that this principle would excessively complicate the implementation of new features.
With this in mind, we have fully embraced the new C++11 language feature (such as lambda function in the asynchronous interface method, or variadic templates) and pushed for extensive use of standard library container classes in lieu of our custom ones.
We know that in this way we may have limited use of the client to more recent platforms (bye bye RHEL 6) but fortunately the source is open and we have a very good build procedure based on cmake that can easily generates builder for the most used pair <compiler model, compiler version>.
The work on C++11 language adoption is still in progress and the goal on this front is to update the code wherever it results in improved readability (i.e. the auto keyword is a simple but powerful way to reduce code verbosity).
Because in this cycle we have added a few new features that required the introduction of some library dependencies and automatic code generation, the build process has become more complex, but we’re doing our best to keep it manageable. We want to ensure that our packaging structure is what users expect on all of our platforms with respect to libraries, headers and documentation.
I will be glad to hear from any of you about any thoughts and suggestions, especially on the portability issues.
In the next post I will show an example of the new Remote Script Execution features.