On Fri, 2007-06-01 at 10:46 +0100, Robert Greig wrote: > On 01/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > As I said, we would not define the NMS API as we do not change the JMS > > API. We would only implement it. > > But we do currently extend JMS, through the use of eg > org.apache.qpid.jms.Session extends javax.jms.Session.
We can extend it but the API itself is not changed. > > 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. > > But to implement it we need a clear understanding of the precise > semantics. If they are defined to be "exactly the same as JMS" (which > itself is open to interpretation in a few areas!) then that is a start > I suppose notwithstanding the legal issues with that. I suppose that the NMS project would have to worry about legal issues. > Does WCF sit easily on top of NMS? If we have Qpid-specific extensions > can they be exposed elegantly with that model? I know a person that already has a WCF channel based on NMS. We would therefor be able to reuse it without any change. We would also gain being compatible with spring .Net. Again, I see a NMS implementation as a way of speeding up AMQP adoption within the .Net community. We will have a WCF channel and a BizTalk adapter, NMS is just an additional advantage for people that don't want to deal with the cumbersome BizTalk. Arnaud
