Rob, These are good points. Let me start with management.
I view Dispatch as a bit of a testing ground for the emerging AMQP Management specification. I would claim that at this point, the specification is not ready for prime-time. With regard to the address, the specification uses "$management". Perhaps I'm mistaken, but I took that to mean "place-holder for an as-yet unspecified literal string". Clearly there needs to be a way to address multiple distinct container agents through the same connection or link. If this is not the case, then it will need to be addressed in the technical committee.
I've personally been tracking both the management and addressing specifications circulating through the technical committee and I expect that Dispatch will conform to (and in fact prove out) both specifications. I'm not aware of any other project within Qpid that is implementing the management specification (perhaps the Java broker is).
With regard to interaction with other Qpid and Apache projects, Dispatch is already proved interoperable with the Proton Messenger and qpid::messaging clients. It should also be usable as interconnect between clients and the Qpid brokers via AMQP 1.0 and between multiple brokers as a federation interconnect. Some experimentation has been done using the ActiveMQ broker as well.
With regard to protocols, I would be opposed to trying to implement AMQP 0-* due to the asymmetric nature of those protocols. I do think, however, that Dispatch could make a very good platform for an edge concentrator for lighter protocols like MQTT.
Regards, -Ted On 10/09/2013 12:20 PM, Rob Godfrey wrote:
Hi Ted, I think before we make this a full sub project, it would be good to have clarity on exactly the proposed scope of Dispatch, how it is expected to interact with other components within Qpid, or within wider AMQP networks. I think in retrospect we didn't do this clearly enough with Proton (for example). Moreover I would personally like to understand which AMQP standards it will be looking to implement, and which not. For instance I notice this line in the docs for Dispatch: *Address**Description* /_local/agentThe management agent on the attached router/container. This address would be used by an endpoint that is a management client/console/tool wishing to access management data from the attached container. Which doesn't seem to conform with the proposed management specification for AMQP, nor does the document make any mention of how dispatch is to be managed. Cheers, Rob On 9 October 2013 17:22, Ted Ross <[email protected]> wrote:The AMQP Router project (Qpid Dispatch, announced previously on the user list) is gaining in community interest and is nearing the point where a first release is appropriate. In preparation for a release, I proposethat this sub-project follow the lead of both Proton and the AMQP1.0 JMS projects. This involves: 1. Moving the code from qpid/extras to http://svn.apache.org/repos/**asf/qpid/dispatch<http://svn.apache.org/repos/asf/qpid/dispatch> , 2. Requesting, by vote, the creation of a JIRA project to track its issues and releases. Unless there are objections, I will move forward with the above two tasks. Regards, -Ted
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
