On Mon, Mar 8, 2010 at 3:16 PM, Rafael Schloming <rafa...@redhat.com> wrote: > Robbie Gemmell wrote: >>> >>> 3. From the next release we need to ship separate binaries for the >>> broker, client and management bits. >> >> We already do release separate bundles for pretty much everything (Client, >> Broker, QMan[management-client], and JMX Management Consoles). From the >> next >> release I would suggest that we stop shipping the 'java bundle' binary >> which >> mashes most of those contents together. > > I'm not really a big fan of not shipping the bundle. > > I think users who OEM the client want to clearly understand what it's > dependencies are and obviously want them as minimal as possible, and I > certainly think this is an important usage scenario to accommodate, however > I think a large part of that can be achieved without having a client-only > download, and I think it's important to recognize that it's not our only > usage scenario. > > Now I'm not really against having a client only download, but I do think the > bundle should be kept, and in fact should really be thought of as the > primary download for the simple reason that a client-only download is > actually quite useless to most of our prospective users because you can't > actually do anything useful with the client unless you have a broker > somewhere, and even then I doubt you'll get very far without some management > tools for simple diagnostics.
While I agree with you that having the bundle is important, I'd also think it's equally important (if not more going forward) having separate binaries for the client and management tools. I believe we should offer both. Increasingly we see our user base mixing and matching components. All though one might be interested in the JMS client, their choice of broker maybe C++ due to a variety of reasons. Also we already have use cases where the Java management tools/libraries are used against the c++ broker. And since the Java broker now supports QMF, there will be users who may want to use the python management tools/API instead of the java based tools. People may even mix and match components btw projects going forward as that is one of the goals of AMQP. IMO we offer three main categories of products, namely AMQP enabled "Brokers", "Client" and "Management Tools". Therefore where possible we should **also** allow people to download individual components. > Contrast this to a download that includes the broker, the client, some basic > diagnostic/management tools, and some working examples, and I think our > potential users will have a much nicer out-of-the-box experience with a > bundle. I definitely see a value in providing a bundle. But I don't think downloading components separately (especially if mixing and matching btw language impls) will in anyway lead to a lesser experience than using a bundle. It all depends on what they want. If they want to mix and match components, then not providing that option will definitely impact their experience as they will have to resort building from source. > Granted our current bundle needs some work to live up to this, but > I don't think that's a reason to throw the baby out with the bathwater. > > --Rafael > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
