On Tue, Dec 1, 2009 at 9:24 PM, Robert Greig <[email protected]> wrote: > 2009/12/1 Rafael Schloming <[email protected]>: > >> 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?
Well, discounting myself (I have a half-baked^Wimplemented system to manage my music using AMQP and Banshee), it's shipped in downstream distros (eg. SLES10) and there was an effort to implement System.Messaging for Mono on top of Qpid but that was ditched for RabbitMQ. So there's clearly some demand for it, although potentially stymied by some FAIL on our part. > 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. TBH the problem, as Rafi points out, is not so much the "built-on-top-of-C++-client" nature (although that would prevent deployment as part of a Silverlight/Moonlight app, or as an iPhone application via MonoTouch) but that the glue is pretty tightly couple to both Windows and the Microsoft CLR implementation. It reaches into it in fundamentally unportable ways, particularly around the locking abstractions. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
