2009/12/1 Rafael Schloming <rafa...@redhat.com>: > I think the point for this thread is that if it is windows-only then it > isn't really a substitute for the existing dotnet clients which work (in as > much as they have ever worked) on mono.
Well that assumes that running on mono is a goal? Do we have any users of the .NET client on Mono? 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? 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? > So the question in both cases is whether or not there is a good reason for > the code (both the WCF impl and the C++ broker) to be platform specific. I can see that it would be nice to have a completely managed code .NET library (for example, I think you need to be fully managed to support one click deployment?). However I can also see that leveraging the existing C++ codebase is very attractive since the core of it has been tested a lot on linux and the port of the rest is required for a Windows broker. It would be interesting to know if this is why the Microsoft guys decided to take that approach rather than rewriting the managed code client. RG --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
