[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Cliff Jansen updated ISPN-470: ------------------------------ Attachment: straw.patch Here is a patch which provides a blueprint for a C++ client implementation. It is a skeletal implementation that allows some tire kicking and opportunity for comments on direction. The source is divided roughly as follows: api, include : the public interface impl: a close match (hopefully) of the Java client/hotrod/impl subdirectory sys: platform dependent code (or 99% of it) Another way of describing "sys" is to provide a means to write platform neutral code in the rest of the tree. The "api" part should feel like a natural C++ use of Hot Rod, as opposed to Java shoehorned into a C++ syntax. By contrast, the "impl" subdirectory should relax C++ ideology to allow the code logic to resemble the naming and logic flow of the Java client as closely as possible without causing brain tumors. It would be nice if this code eschewed fancier C++ techniques and perhaps even enticed the occasional Java developer to lend a hand. For an example (that can still be improved) see how RemoteCacheImpl.cpp attempts to match the Java client's RemoteCacheImpl.java for get and put. I have been a contributor to the Apache Qpid project for many years and should state up front that my biases are mostly shaped from there, including working on its newest Proton messaging library. Build system: This patch uses CMake. It builds on RHEL 6 and in Visual Studio 2008 on Windows (release mode only currently). Testing: TBD. Proton has used SWIG to good effect to verify that the Java and C bits are in sync. Hopefully that is possible here too. Scripting: i.e. scripts needed to support the build or test setup. I would suggest using one scripting language, e.g. python. Qpid used to have a combo of shell scripts (POSIX) and batch files/ powershell scripts (Windows). Proton adopted python as the sole scripting and that has been quite an improvement. Coding guidelines: I would propose https://cwiki.apache.org/qpid/cppstyleguide.html Its rules are quite consistent with writing C++ code that closing matches the Java coding style of the Hot Rod client. Finally, since a Hot Rod by nature is light and nimble, memory allocations to the heap, locking primitives should be avoided when possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira