[Mono-dev] System.Messaging, a (just) working implementation
mike at middlesoft.co.uk
Fri Apr 25 17:46:12 EDT 2008
> I was hoping by adding a provider layer, other implementations could be
>> added later, e.g. OpenWire for ActiveMQ or something Mono specific.
>> And as Miguel pointed out, we would have to avoid your GPLv3-based
>> as run-time dependency.
>> I didn't see Miguel's message, but that is my mistake, it shouldn't of
>> been v3. Is LGPL okay or would MIT be easiest for Mono?
>> LGPLv2 is at least still valid, but MIT/X11 is the least problematic.
> To summarize the situation, there are three assemblies that play certain
> - System.Messaging.dll
> - Mono.Messaging.dll or whatever, that contains IMessagingProvider and so
> - The actual implementation of IMessagingProvider.
> No functionality in System.Messaging would work without the last item, and
> it is loaded by the runtime, it should not conflict with LGPL2-licensed
> Actually we cannot distribute your IMessagingProvider implementation (the
> hosted at code.google.com) inside our mono source tarball because it
> pre-compiled dependency libraries and hence does not match current build
> of mono/mcs tree.
> It is sort of mess and basically I would like to avoid this implementation
> strategy. When we provide working System.Messaging functionality we will
> to provide another package and source tarball just for this bridge
> Unlike NMS in ActiveMQ or AMQP implementation in RabbitMQ, this Qpid stuff
> too rich and has a lot of external dependencies, which do not look suitable
Yes, the QPid client libraries are very dependency heavy (around 8 dlls). I
was keen to get something working as quickly as possible and it was CLR
based AMQP client library I could find. I am reasonably familiar with AMQP
protocol format so a producing a clean client implementation to include in
the mono distribution (as a final solution) won't be too difficult.
However, I think getting the System.Messaging and Mono.Messaging (or
whatever name is appropriate) assemblies in place first is probably best, so
I would probably use the QPid libraries as a means to have a working
implementation as early as possible.
My next step, likely in September, would be to separate Mono.Messaging into
a separate assembly and remove references to the System.Messaging
namespace. Once that works, build a AMQP client library that does drag in
so many dependencies.
> I have some comments on the patch details, but I'd put my general
>> survey first :)
>> Atsushi Eno
>> Unfortunately my timing here is not the best. I am about to head off
>> travelling for about 4 months, so I won't be able to make any major changes
>> until September. I'll fix the license and add MessageQueue.Create support
>> before I go. I still want to help build a System.Messaging implemenation so
>> I would be happy to receive any feedback you have in order to build
>> something that will be useful for Mono. System.Messaging hasn't been
>> touched a few years, so a few more months shouldn't hurt :-).
>> Oh. Okay. Though it has not been touched for years, I once tried to
> implement some basic functionality using OpenWire.net, and there was an
> attempt to implement it using AMQ as Summer of Code project. A few more
> months wouldn't hurt but someone may start it instead of you ;-)
I'm okay with that. If someone makes better progress in the meantime, I
would be happy to contribute to their efforts.
> Atsushi Eno
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list