On 25/04/2008, Marnie McCormack <[EMAIL PROTECTED]> wrote:

> If there are RMG docs that cannot be contributed (have not been) they should
> not be sent out to Qpid users. Apart from anything else, it is confusing for
> newbies. I'm a bit frustrated here since we are project-wise not great at
> documentation across the piece. I'm trying to get there, and I'm hoping we
> all are ...

My views on this specific issue are:

1) I would hope that Red Hat could contribute generic docs
(programming guides, options etc.) to the Qpid website

2) It is obviously right that installation instructions that are
specific to RHM are hosted on the RHM site

3) For users who are running on Red Hat linux, I can see that RHM is a
great way of installing and running Qpid and I have no objections at
all to linking to that on the Qpid website. This is no different from
similar links on other projects, e.g. on Eclipse to commercial Eclipse
bundles that package various plugins etc.

> I'm a bit bemused about why the qpid-dev list is the right place for
> discussing other AMQP offerings, particularly commercial offerings.
> Absolutely we need to be (and discussing our) AMQP compliance. I don't see
> that this extends to particular products ?

I think that this just reflects the practicalities of protocol
implementations. Different vendors will have slightly different
interpretations of particular parts of a given version of the
specification, or may have not fully implemented the protocol. Over
time this will be be less of an issue and "AMQP compliant" may well be
good enough but the stark reality is that today users need to know
more than that.

There are other reasons why we will be need to mention commercial
products. For example, if someone asks "how do I integrate Qpid into
WebLogic".

> We don't discuss interop with other JMS provider products ....

Probably because we don't interop with any other products as far as I am aware.

> However, we need to be seen to be fair. Are we going to discuss/diagnose
> problems interop-ing with other commerical offerings in this space (without
> having tested or stated interop) ?

I think that assisting and diagnosing problems with interop with our
users will help them. Many of us will be able to track down problems
very quickly, and some of us may have tested interoperability with
other products (in at least some cases). Through this process we can
improve Qpid because there will inevitably be cases where Qpid is not
doing the right thing or the best thing.

RG

Reply via email to