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.
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.
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
