This is just one of those bullets that we have to bite on.
AMQP is "getting there", seeing what the low level API shapes out as is part of the stabalising process. Top down design / bottom up design -- need both at the same time in my experience. On 12/06/07, Robert Greig <[EMAIL PROTECTED]> wrote:
On 12/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > I don't think we should expend too much effort in that direction > purely as Qpid. Further, there will likely be more changes after 0-10 > (although hopefully of a smaller magnitude), before we get to AMQP > 1-0. > > I suggest that while we may start thinking about an AMQP API right > now, we do not try to prematurely standardize. > > My suggestion remains that we use (in the Java version at least) an > "AMQP"-style API internally; and that early adopters *may* wish to use > this API but must do so with the knowledge that its is likely to > undergo change which may not have backwards compatability. > > From an interoperability point of view; the other important area we > must cover is to have the other Qpid clients easily able to produce > messages that are understood in JMS. For instance being able to > easily send "text", "stream" or "map" messages. This will need to be > standardized for AMQP - but for the moment at least having > interoperability at this level between the AMQP clients would be nice. Completely agree with all of the above. The discussion of an AMQP API has come up several times in the past and I think given how much the protocol has evolved/is likely to evolve it is still too early to focus on attempting to create some kind of standard API. RG
