Rupert, while we in Qpid may wish to start having ideas on an API... the AMQP group has indicated it as a goal to have such an API deifned by AMQP.
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. -- Rob On 12/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
John, If this is to be the agreed way forward, I think it makes sense to start defining that API as soon as possible. Rather than begining coding for the 0.10 spec in an ad-hoc way; I think it is worth investing a little bit of time in deciding up-front the shape of that API prior to coding. Personally, I'm +1 for this idea. Rupert On 12/06/07, John O'Hara <[EMAIL PROTECTED]> wrote: > > > > > I'm going to bet that your average development shop is willing to > > sacrifice a little bit of performance of feature access in order to > > gain the ability to choose between messaging vendors. APIs are what > > usually lock in an application to a specific vendor. If the > > application uses an abstract API, vendor lock in can potentially be > > avoided. > > > > 100% true. Which is why most applications have their own shim layer too > :-) > In some ways, WCF and BizTalk are Microsoft's shims. > > Perhaps we're at concensus here: > > 1) Do non-Java API's for Qpid that is not constrained by the JMS > legacy. In > all liklihood, the same shape of API will be available for Java too, just > for completeness, in addition to JMS support. > > 2) Build a WCF driver for Qpid, atop 1) > > 3) Those who are interested can map NMS to 1) also. > > Now we just need to decide the shape of that lower level API. > There is a lot of talk in the AMQP camp about doing a standard shape API. > We already have some candidates in the wild from iMatix, Apache, and > Rabbit, > and there have been side discussions about having a beauty contest or > doing > pick'n'mix. > > The API needs to look good and feel right. I get terrified when I think > of > the last thing that tried to standardise an API shape across languages -- > DOM. I'm sure we can have something nicer looking than that ;-) > > Comments? > John >
