All, Changing the title to be a bit more direct about the issue at hand (in my opinion).
I think the main concern I have about ARTEMIS-780 is the implicit ramifications on creating a 2.0 release. Granted, I missed the original note, but then when it was mentioned in a further discussion as having impact I questioned where it had come from. (realistically, saying there's a branch doesn't given much info about why there's a branch) We run into this kind of problem a lot in the Apache Incubator, when a company donates some amount of code to the ASF and has salaried employees work on that code. Typically what happens is those employees have their own internal backlog and figure out where the code has to go (e.g. Apache). There's nothing wrong with that model. However, in the spirit of building a community, we need to encourage that when things are coming into the ASF code base there's a general understanding of what the idea is, and how to get others involved in it. The evidence from ARTEMIS-780 is that there's a high volume of discussion happening around how to implement it, not on any of these lists. My ask to the overall community is to try to keep the entire ActiveMQ community engaged in large impacting discussions like this one to help foster more information, give those of us who aren't as familiar with the code a better understanding of how changes are coming in and what those changes are. John On Fri, Nov 11, 2016 at 5:26 AM Martyn Taylor <mtay...@redhat.com> wrote: Hi John, Apologies for not getting to this sooner, I have taken some time out to write up more background , problems and what the proposal is. I'll add it to the JIRA as soon as I'm done. The crux of this change is adding the ability to define various destination types / behaviours (things like being able to define a non shared subscription queue for example) in a single unified way in core vs on a per protocol basis (like with JMS). The fact that adding common behaviours like simple pub/sub in the protocol modules, and having no way (other than JMS which has it's own issues) to allow a user to define a pub/sub endpoint has been a real issue. This would also involve moving the current JMS way of doing things, to the new model. And is actually the main bulk of the work. As It turns out. the current JMSisms have leaked into many areas of the core engine and other protocols, trying to remove it has been a pain. I already had an idea that this would be the case, hence the branch., but turned out to be a lot more that I had expected Re: Your use case, just to assure you, the idea is not to remove any of the existing core concepts, everything you can do now, you'll continue to be able to do after the change. There might be some slight configuration changes in the new scheme to expose new functionality and move away from the specific JMS stuff, but I'm going to provide a tool for migrating configurations (the changes aren't big, just the exposing of the new addressing model and removal of the JMS specifics). I look forward to talking to you more on the JIRA. I also like to hear use cases from Artemis users :) so I'd be interested to hearing more about what your doing. It might be that these changes make things a bit easier for you. Cheers Martyn
