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
