> Are there links explaining the role (capabilities, responsibilities, etc)?
This is a good place to start [1]. To be clear, this is just an idea at this point. > Microsoft still maintains a modicum of MS-DOS comaptibility! I'm not sure that's a particularly valid comparison. Microsoft is a large corporation that pays their developers to maintain the backwards compatibility you mention. To my knowledge, nobody is paying anybody to maintain the activemq-cpp client so it's done on a purely volunteer basis, and this is the crux of the matter. There is only so much time in the day, and the current state of the activemq-cpp client is a result of folks prioritizing their time according to what they value. All things being equal I think most of us would want to create the best C++ messaging client on the market, but all things aren't equal. Apache is more about community than code [2] and my concern is that the community simply hasn't coalesced around this code-base sufficiently to sustain it on an ongoing basis. > But I'm well aware that most programmers would much rather be working on Brand New Stuff... That may be true enough in general, but I don't think that's true of folks in this community. > ...I got the same bangs for a much smaller buck AFAICT with a bare-bones implementation of STOMP... In many ways this proves a point I was trying to make earlier. Given the lack of resources and interest in maintaining activemq-cpp combined with the effort it would take to not just make it work but work well, why wouldn't we simply point folks to alternatives like STOMP and AMQP. For example, if you have a simple, synchronous use-case then STOMP is a great solution. Or if you have a more complex use-case that needs async and stuff like flow-control then AMQP is a good fit. I would be happy to see folks step forward and embrace responsibility for this code-base. If not, I'm also happy to declare this code-base EOL. What I'm not happy to accept is this continued limbo where valid problems never get fixed and there is no clear communication as to why and what the future holds for the code-base. In my opinion this situation is worse than either of the previous two. Justin [1] https://infra.apache.org/new-committers-guide.html [2] https://theapacheway.com/community-over-code/ On Thu, Feb 13, 2025 at 1:55 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 > > >
