On Wed, Jan 28, 2009 at 8:01 PM, Robert Greig <[email protected]> wrote:
> 2009/1/23 Aidan Skinner <[email protected]>: > >> 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. IKVM should support all of the JDK 6 API now, it uses OpenJDK (nee GNU Classpath), and ships java.nio in it's core package, so we might be able to get away without too many extra bits and pieces. > 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. Totally. Having something which feels natural is really important. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
