I'm not sure how this proposal fits into the existing ActiveMQ solution at this point. It should be feasible to start down this path and consider how it fits later down the line.
Giving it a little thought right now, one possible approach would be to get the API defined, and then make a new messaging solution by taking key ActiveMQ features (e.g. virtual topics) and putting them into a new artifact that uses the Engine API. I have another concept that may help to see how this proposal innovates. This borrows from the "use before reuse" idea. Instead of creating a single messaging solution (or broker), having a toolset for creating messaging solutions makes it possible to better address diverse needs. Another concept... We have socket, filesystem, and other APIs that make networking, file storage, and other needs in applications easy. There are multiple implementations of these APIs (every O/S has its own). And we have messaging APIs (e.g. JMS) that makes messaging in applications easy. In between, we have large solutions (ActiveMQ, XMPP, etc). What would happen if we split that middle into two parts: one that brings up, from the bottom, a "messaging engine" or "messaging primitives" API, creating a space coming down from the top into which multiple implementations can be placed and more easily developed? Creating the best fit... -- View this message in context: http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694144.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
