> -----Original Message----- > From: Aidan Skinner [mailto:aidan.skin...@gmail.com] > Sent: 29 April 2009 18:42 > > On Wed, Apr 22, 2009 at 4:11 PM, Robbie Gemmell > <robbie.gemm...@gmail.com> wrote: > > > One upcoming elephant to consider is going to be AMQP 1.0 support and > > how its new messaging/component model will affect the management > > interfaces. As the Java broker is presumably going to support the > > current protocol versions and gain 1.0 (+ 0-10), this could/will > > somewhat muddy the management waters. > > I think we should exclude Desired Future Endstate from consideration > for this work. The 0-10 stuff is obviously relevant, since it will be > taking place concurrently.
Ok. I only really mentioned it due to past discussions where interest was expressed for doing 0-10 in concert with/on top of 1.0 work, so I figured any discussions there might get slightly intertwined. > Having said that, I think that there's definitely some work that can > be done to improve the current API. > > > presumably mean some methods being added, removed, or possibly moved > to > > new/existing MBeans. Alternatively, an entirely new set of JMX > > interfaces could be exposed and coexist with the existing set to > handle > > the new model and old models seperately, moving to just the new set > at > > some future time. So many possible options... > > We're going to need to keep the existing API for a bit, if we're going > to be breaking stuff I strongly feel we need to do it for everything > at once (server config, client APIs etc). +1 Any discussions of major change were only in reference to any 1.0 consideration, I don't think there is any other point on the horizon that justifies/requires break-inducing changes being considered. > > Creating a new one entirely might not be inappropriate, but we are > going to have to coordinate it with qpid-cli amongst others. If we do > decide to do this we're going to need to do some requirements > gathering. > > > Another issue for discussion is versioning. In the previous work I > did > > on the broker JMX capabilities, some issues cropped up with > > compatibility due to a required a change in the expected input (going > > from MD5-hashed password input to plain text to support a consistent > > user management interface) for some of the methods. Additional > changes > > included altering of some attribute units for correctness and > > consistency, and introduction of some new attributes for FTD (since > > removed). These changes made it necessary and/or desirable to be able > to > > distinguish the versions of each JMX MBean encountered, so a version > > property was added to the JMX ObjectName to do so. Depending on > changes > > made to account for 1.0 management, it may be necessary or useful to > > rework this as well. > > This makes doing that a bit easier. It's not something we want to do > lightly but it might be helpful. :) > > One question we really want to solve is how to add functionality in a > less intrusive manner. Once we reach a stable API we're going to still > need to be able to extend it, and have plugins contribute their own > management functionality easily and portably. > > - Aidan Indeed, although extending stuff in general doesn't need to be as messy as the above bit was. That was mainly the result of changing the required input or units of existing functionality because it was totally braindead :) --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
