On 01/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Standardizing on APIs that others are already using sounds like a worthwhile thing to me.
I certainly think the performance impact of the layers is important to consider. 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. Now I am not terribly familiar with .NET but from my casual observance it appears that WCF is likely to be the standard API that people are going to be familiar with. If that is true, then I should have thought that WCF ought to be the basis of our client implementation with any Qpid-specific functionality available through that API (I have no idea how it works for extension points etc.) 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. 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. RG
