On Mon, Mar 8, 2010 at 6:09 PM, Rafael Schloming <rafa...@redhat.com> wrote: > Rajith Attapattu wrote: >> >> 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. > > Part of my point is that we need to distinguish between downloaders and > users. A first-time evaluator of our project really just wants to download > something that works out of the box. I think when you get into mixing and > matching, that is really something for more established/serious users. Fair point !
>> 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. > > As I said before I don't disagree with providing separate bundles, I just > don't think it is the audience we should be advertising to on the download > page. > > I also feel that a broker only download is particularly useless as you can't > even do something as basic as getting a list of defined queues or exchanges > without getting the management tools, and while we may be somewhat numb to > how odd this is because we've accepted it for so long, I think if you put > yourself in the mind of someone new to qpid, it makes our download artifacts > particularly frustrating and unfriendly. > >>> 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. > > I actually think a reasonable bundle would need to include more than one > language impl since the management tools are in python (and require the > python client), and IMHO they should come with the brokers. I agree with you here. I think you made a good point about first time evaluators vs experienced users who would be using Qpid in development etc. >From a first time users perspective I can definitely understand the value of downloading something and getting it to work out of the box. And I agree that this is an area that we haven't really paid much attention too. Ideally a broker download should accompany the client libs, management tools and examples (that interop) along with documentation. That would no doubt help a new user tremendously. > Likewise a compelling out-of-the box example should really show interop > between clients in all the different languages. > Either way though, I don't think you would ever need to build anything from > source. Assuming a sanely organized bundle, it's really just a tradeoff > between requiring a first time user to download as many as six different > components to get a full working system, vs requiring an established user to > download the bundle and pull out just the part he cares about. > > Obviously once you have such a sanely organized bundle it is trivial to pull > out the components and offer them as well, but my point is really that the > focus should be on defining the bundle, because if we think about each > component separately, then we're going to end up with many different > components that are useless in isolation, yet don't really fit together in > an obvious way. > > --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
