On Thu, 13 Feb 2025 11:20:22 -0600, Justin Bertram <jbert...@apache.org> wrote:
| Rather than forking I think it would potentially make more sense for | you to become a committer here at Apache. I have no idea what I would be signing up for! Are there links explaining the role (capabilities, responsibilities, etc)? Thanks! | Then updates could take place in stages. I think the first step | would just involve getting things working on C++17. Getting it to compile on C++17 is basically a solved problem: needing only two JIRAs to be acted upon. (AMQCPP-664/628, AMQCPP-718). However, that leaves 196 warnings. The vast majority of these are easy to fix (arising from lack of attention to the Rule of Three - now the Rule of Five.) Some warnings are potentially serious (such as some apparently 32-bit specific hacks that could become bugs in a 64-bit build.) | Larger changes would come later. Changes to the public API would | require a new major version. I would focus on internal changes - where there's _plenty_ to be done. The public API is a separate issue, but probably worthy of discussion. The basic point here is why a C++ API at all? Heavyweights in the MOM space (I have Tibco EMS and Solace in mind) offer C APIs to equivalent functionality. There is a very important reason for this which, I'm sorry to say, would likely be lost on the average Java or Java-influenced person: C++ _strongly_ prefers stack based allocation. Even in the C++ world, libraries that have objects maintaining internal state often expose them via opaque pointers and external functions (with _both_ createXXX(...) and destroyXXX(...) calls.) Tibco EMS and Solace do precisely that. Writing wrapper classes in C++ to control lifetimes is then trivial. There is _no particular benefit_ to exposing ActiveMQ objects as C++ pointers. Tibco EMS is a fairly faithful translation of the JMS API; there's no reason this can't be done here as well - with an optional compatibility layer added on top for those already relying on the C++ API. | Given this, it's not clear to me that continued investment in CMS | (and the C++ implementation) makes sense. Clearly the folks that | originally championed this stuff have moved on to other things. Microsoft still maintains a modicum of MS-DOS comaptibility! Keeping tried and true software up to snuff - basically ensuring that source code can still be compiled safely - is never a truly wasted effort as long as there are users of it. But I'm well aware that most programmers would much rather be working on Brand New Stuff (TM) :-) | I'm curious if you've tried (or considered trying) the Qpid Proton | C++ client [1]. I looked into it briefly some years ago. What I saw then was hair raising. I'll have to look into it again, though my initial impression (from the Tutorial link) wasn't inspiring: it looks over-engineered. Simplicity is the watchword in a number of MOM-based applications. I chose ActiveMQ for a project because of some desirable features in the server. The C++ client was an albatross, to put it unkindly. It worked robustly, but I had to treat it like a black box - 15+ minutes to compile once and use the binary in the project source. The memory footprint was kind of large as well. As an experiment, I got the same bangs for a much smaller buck AFAICT with a bare-bones implementation of STOMP[*]. Beware over-engineering! Arjun [*] https://github.com/arayq2/utility/tree/master/Stomp --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
