2009/12/1 Robert Godfrey <rob.j.godf...@gmail.com>: >> IKVM is a way of running Java. I have no idea whether IKVM implements >> enough of the JDK libraries to enable the Qpid Java client to run >> under it but let's assume for the moment that it does. Further, let us >> assume that some important change in 0.6 or another upcoming release >> breaks that. Do we say that we should not proceed with that change >> because IKVM isn't supported? >> > Not quite the same thing is it? A better analogy might be to imagine that > the JMS client required the use of the compiled C++ libraries and say we > only supported Java on Windows and Linux... I think that to have implemented > the JMS client in that way would have been a poor choice.
Well, my point was that IKVM is a very small niche platform only likely to be of interest to a tiny percentage of users. While I accept that mono is a bit bigger than IKVM I'd still argue it's small enough not to put any special effort into supporting. As I mentioned, I agree that cet. par a managed code .NET client would be better but I think the analogy with JMS isn't quite right because we're starting from a different position. When we built the JMS client there was no stable C++ client on any platform. It is also true that for Java there were several platforms we needed to support out of the box. Finally, there are performance issue with managed/non-managed heap copies in Java that makes JNI unattractive (I don't know if this applies to .NET too - although I did ask the question on this mailing list some time ago without receiving any answer). If your goal is to deliver a robust .NET client on a single platform in a short timeframe going down a non-managed hybrid route doesn't to me appear unreasonable. >> I think it (fairly obviously) depends on the demands of our users (and >> our perceptions of those demands). How many people want a .NET client >> that doesn't work on any platform versus a WCF platform that works on >> Windows? >> >> > These goals shouldn't be contradictory. Unless (perhaps) you add a time/cost goal into the mix. Although I concede that I haven't done a detailed analysis on that personally. > I think the above (building WCF on top of a lower level messaging API) > should be our goal. And further we should attempt to make that lower level > API as independent as possible of particular AMQP versions (given the > upcoming release - hopefully - of AMQP v1.0). > > My understanding is that Gordon, Rafi and others have been working hard on > defining an abstract messaging API not bound to a particular version of AMQP > but informed by AMQPs capabilities. Further that the C++ and Python clients > will be implementing this API so that each of these clients will implement a > common API (obvious language differences aside). I do not think it an > unreasonable goal that we implement such a common low-level API across all > our clients; and build things such as JMS and WCF on top of those (expecting > that 90% of the user population in those languages would use the WCF or JMS > api). Having such a common low level API would also, one hopes, make it > easier to transfer from a non-managed code underlying library to a managed > code library for .net. I agree that it would be very much worth exploring this. Once the common API is implemented in C++ it should be no problem to expose that directly in .NET :-) RG --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
