On Fri, 2007-06-01 at 10:21 +0100, Robert Greig wrote: > However I would argue that having the same API across different > languages is not actually that useful in all cases. In particular, > where there is an established API in a language/platform that users > are "likely" to be familiar with or use first. > > In the Java world, we obviously have JMS and that is why I have always > said that no matter what we think of JMS any Qpid API must be an > extension of JMS not a different approach. The situation where you say > to users "if you want to use <advanced feature x> you need to use our > other API and rewrite your application" is just unacceptable.
+1 > Having another API that we would support that sits under WCF is just > making work for ourselves. If you have an API you have to document it, > you have to promise to support it and not change it randomly from > release to release and you have to be able to justify to users why you > have several APIs. As I said, we would not define the NMS API as we do not change the JMS API. We would only implement it. > On the subject of NMS, are its semantics documented carefully? We know > from our experience of the JMS TCK that without clear and precise > documentation (and ideally a test suite) it wouldn't really offer > interop. Having an API isn't enough - for it to be worthwhile you need > to offer users clear semantic guarantees. I don think that implementing NMS would impact upon interop. An I agree with you that having an API isn't enough but again I am suggesting that we define it but that we implement it. Moreover this code should not even be hosted by our project but rather on the NMS Apache project. Arnaud
