On 9 October 2013 19:06, Ted Ross <tr...@redhat.com> wrote: > 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. > > "$management" is meant as a literal. When you pair this with global addressing you can define addresses for each of the management nodes in separate container instances /<instance A>/$management /<instance B>/$management, etc... moreover you may wish to have the management node at each instance aware of the management nodes of instances to which it is connected, thus by issuing the discover commands to the management node at the local router you have connected to you can potentially find all management nodes in the connected network.
> 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). > > My main concern is that I believe that Qpid should be primarily directed at implementing AMQP standards, and building resuable toolkits and components that fit into any AMQP network. I'd be very concerned if we were inventing alternative management protocols, or building components that only interoperated with other Qpid tools. So, personally I'd like to see statement around components saying that they will be fully implementing emerging AMQP Management, AMQP addressing, etc. standards, and that we as a project then ensure we stick to these goals. > 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. > > I guess what I'm driving at is that it would be good to have a proper scope/charter statement for each of our "components" that we as a project had broad agreement on which do restrict us from just dropping anything we feel like into a component. I'd like to do that for Dispatch before we elevate it, and I think we should ensure that we also have such statements for the JMS client (which I think should be easy) and Proton (which may be a little trickier). Cheers, Rob > 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 <tr...@redhat.com> 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> >>> <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: > dev-unsubscribe@qpid.apache.**org<dev-unsubscr...@qpid.apache.org> > For additional commands, e-mail: dev-h...@qpid.apache.org > >
