qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 18:30:49 GMT
> 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.

Obviously one can pack any type inside a longstr, including a FieldTable...
but just because one can do something... ;-)

Seriously, although I wasn't party to the original proposal on additional
types, it seems to me that it is a better solution to define new types than
to hack these distinct types into longstr.  There does not appear to me to
be a huge development cost in adding these to the protocol (mostly these can
be treated as pass-thru by the broker), and if we are defining a standard
way of implementing JMS compliance then we need a way to differentiate
between these types, and the alternative would be to define standard
encodings inside a longstr, which seems needlessly inefficient.  I would
think that one of our goals would be to make the protocol as efficient as
possible - every byte we can save, we should.

I agree that a client should be capable of working in strict AMQP mode where
these extensions are not used.  However this would be at the cost
(currently) of JMS compliance [there are other non-standard extensions to
the protocol other than just the FieldTable types - if it were just the
FieldTable types I would agree that it would be an unnecessary deviation
from the spec.  However there are bigger issues.].

Until we get changes to the protocol agreed, we can be AMQP compliant, or
JMS compliant, but not both simultaneously (on a given connection).

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.

How can we determine that when the destination of a given message is not
known when it is sent?  Are we proposing that the broker is responsible for
re-encoding the message?

As we can see in the discussion over 0-9, the protocol is in a high degree
of flux currently.  I think that anybody who uses QPID at the moment has to
be aware that neither the protocol nor the product have reached the level of
stability and maturity where one can expect seemless interoperability (as
reflected by their version numbers).  Therefore anyone currently deploying
QPID should be free to make the decision as to whether (for instance) JMS
compliance, or interoperability with non-QPID clients is their requirement.
We also have to be very clear what (possibly partial) version on AMQP any
release is going to support.

 Until we approach 1-0 I do not believe it is wrong to implement something
we believe will become part of the protocol (and I believe this is the path
we should take when we implement the 0-9 WIP) as long as it does not
fundamentally break the ability of AMQP compliant clients to communicate
with the broker .  To this point I think the Java client errs in not
providing an AMQP mode where the non-standard extensions are not used.

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

I believe the new types have been put as a proposal, however we need to push
to get it adopted.

Again, I agree that we should be attempting to stay true to the protocol.

I guess my personal rules would be these:

1. We should never make any change to a QPID broker which will stop
compliant AMQP clients communicating through the broker.
2. Every QPID client should always be interoperable with every other QPID
client and the QPID broker for a defined "release".
3. It must be possible to configure the clients so that can
communicate through any compliant AMQP broker to any compliant AMQP client.

currently I think we may be breaking all three rules :-)  We are certainly
breaking 2 & 3.

As we get closer to a 1-0 release of the protocol I would expect that our
rule will be there are no deviations from the protocol.  Fundamentally every
deviation we make from the published protocol is *very bad*, and we should
have been documenting these more clearly.

- Rob

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message