Martin Ritchie wrote:
2009/1/30 Marnie McCormack <marnie.mccorm...@googlemail.com>:
I think our download page should be just that !
There's a release compatibility matrix which shows which bits currently work
together - so I don't think the download page is the place to try and convey
this info. The python client (as the Java client) appears to be the same
package on both tables.
The current download page needs changed - it could be taken to imply to a
user that the java client and broker do not interop. Some info about interop
could be added, to explain that the C++ broker is not backwards compatible.
Marnie
Some of this discussion is really about interop and backwards compatibility.
D
On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie
<jonathan.ro...@redhat.com>wrote:
Carl Trieloff wrote:
I'd prefer not to be separating components from the same release out by
AMQP
version as I think it sends the wrong signal and is not how we actually
make
releases i.e. we released M4 not AMQP 0-10.
that was me, to try make it really easy to know what works with what,
based on some questions on
the user list. Is it not clear that it is not all part of M4? ideas to
make it better...
I liked the way we had it, but I'm happy with any approach that makes it
very clear which pieces are compatible.
I really don't want people to download incompatible bits, shrug, and move
on to some other implementation.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
But are the C++ client and the Ruby client not the only two that don't
work with the Java Broker?
Java, Python and .Net all work with 0-8/9 and 0-10?
As there are more clients that are compatible than are not I'd say we
should put a caveat on the two incompatible clients, if the
compatibility matrix is not enough.
Splitting the download page by AMQP version suggests that the Java
broker is not as functional because it doesn't support the latest
protocol version when in reality only two clients don't work. If we
hadn't deleted the 0-9 C++ client then we would still have a C++
client for the Java Broker and so compatibility issues wouldn't need
to be mentioned. Was the old Ruby client that supported 0-8/9
discarded when the 0-10 work was done, I'd say we should bring it back
in a similar way to the .net unless we plan on putting multi-protocol
support in to the current Ruby client. Was that not the only AMQP
0-8/9 Ruby client?
Actually the 0-8/9 ruby client is still there and should still work. I
think the bigger issue is that other than JMS, the client APIs are
different for 0-8/9 and 0-10, so it's still possible to get confused and
think that there is no interop even though there is.
As an aside, speaking of JMS, we should probably put JMS somewhere near
the Java client entries on that page in order to make it clear that our
Java client is actually a JMS impl.
It is a matter of presentation to users, the fact that the 0-10 has
twice as many items as the 0-8/9 suggests that it is in some way
better, when the 0-8/9 items are duplicates from the 0-10 section.
When we get to M5 and release individual packages for all components
(not just .Net) then I think things will be easier but for that to
occur I think the download page should be grouped Brokers and Clients.
I think this will work just now and be clearer to the end user.
What do you mean by release individual packages for all components?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
