qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Simon <asi...@redhat.com>
Subject Re: [.Net] NMS
Date Fri, 01 Jun 2007 09:37:06 GMT
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.


> 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. 


View raw message