qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 15:21:31 GMT
On Wed, 2007-01-17 at 12:25 +0000, Gordon Sim wrote:
> Achieving JMS compliance has necessitated some non-standard protocol 
> extensions/alterations. To use all JMS features, only a broker that 
> supports these extensions/alterations can be used (currently only the 
> java broker[*]). Further, the java client can not at present be used in 
> *any* capacity with a broker that does not support these extensions.

Question and suggestion about this general topic:

Why weren't the new types simply packed inside a standard longstr? 

I see the value of adding new framing types like wide strings that would
be of general use to any AMQP implementation, however I don't see much
value in producing a non-interoperable AMQP implementation.

My feeling is that 
1) Any new feature in Qpid should be implemented using standard
extension points in AMQP unless it is utterly unfeasible to do so, and
if that's the case there should be discussion to establish that it
really is utterly infeasible - and that discussion should spill onto the
AMQ protocol lists to highlight the shortcoming of the protocol.

2) Any feature that does make non-standard extensions to the protocol
should ensure that it *never* sends such extensions to a peer unless it
understands such extensions. There is a standard field table passed
during connection setup that would allow implementations to identify
themselves for such purposes.

3) Any new feature of qpid that is successfully implemented using
existing protocol features may still prompt a protocol change and a
simpler implementation when the new protocol is published.

E.g. I would prefer to have seen the current issue implemented first
using longstr, with a propposal to the AMQP working group to add
wide-string to the basic framing types. 


View raw message