2009/1/23 Aidan Skinner <ai...@apache.org>: > Traditionally, the approach to writing the .Net client has been to > transliterate the Java client by hand and slap a random API on top of > that. That seems like a bit of a waste of effort to me. I was thinking > about using IKVM to load the Java client as a library for the > AMQP-level bits and write a native C# implementations of WCF etc. that > used that. > > This has the benefit of using an existing, tested client > implementation, reducing the amount of work that needs done and would > help us seperate the AMQP specific bits of the Java client out from > the JMS specific bits. It also means that the whole client is running > in managed code, which is good. > > What do people think?
This is something we considered a while ago when pondering the very first .NET client. At the time it was scuppered because IKVM did not support NIO. I definitely think it's worth looking at again if IKVM now supports enough API to make it feasible. I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. RG --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
