There's a lot here. I'll try to hit a couple of key points. First off, while it would be awesome (in my opinion) to have active C++ developers on the project to maintain activemq-cpp (or a replacement), there is a process to becoming a committer that is important to follow. I wanted to mention this so there are no broken expectations.
Looking at AMQCPP-628 <https://issues.apache.org/jira/browse/AMQCPP-628>, yeah - I get it. After offering some effort and the ticket gets closed with "won't fix" and no comments - that's discouraging. I can't speak for Tim Bish and why he handled the ticket that way. I will point out he was the key maintainer of activemq-cpp and we don't have another maintainer taking up the slack now that he is off to greener pastures. On the technical front, there are things to consider/digest here: - The activemq-cpp library contains a full implementation of the JMS client for C++, including the OpenWire implementation and JMS constructs (connection factory, etc). - There may be additional features there - I would need to go refresh my memory (e.g. thinking of failover transport, protocols besides openwire, and activemq-specific controls/features like individual message ack). - It's unclear to me, and I suspect most of the PMC, just how much activemq-cpp is used across the community. - Technically, any library that implements one of the several protocols supported by ActiveMQ classic and/or Artemis could be used by C++ applications to work with those brokers. - A replacement for the existing library could be a viable alternative to fixing the existing one. - Of course, anyone is free to develop one. - If one were implemented and offered as a contribution to the Apache ActiveMQ project (with the appropriate licensing and copyrights), we can consider to accept it. - The same concerns with maintenance would be an important consideration. - Are there other languages to consider here? (rust?) - Since C++ compilers are quite varied, and at Apache, the source code is the deliverable, this also raises the question of which target environment(s) (O/S, compiler, ...) we use internally, and which we ensure are able to build the project (one of many things I don't miss after moving over to the Java world). That takes me to the question, "how do we move forward from here?" Here are some of my thoughts: - I am willing to put some effort on building and testing activemq-cpp. Note though that my time is limited and it's been a long time since I was a full-time C++ developer (hence the original topic of this thread - have even considered using ctags). - I can also dig around to see what features/functions are included in that project. - It would be extremely helpful (if feasible) to hear from members of the community on their uses of the project, and what they need and care about. - We can revisit the Jira tickets - I believe they are AMQCPP-664/628, AMQCPP-718 That's the dissertation. I hope we can perhaps tackle this in more bite-size pieces. Art On Thu, Feb 13, 2025 at 12:46 PM Arjun Ray <ara...@gmail.com> wrote: > 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 > > >
