[Mono-dev] System.Messaging, a (just) working implementation

[Michael Barker]

>
>
>  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
>>    component
>>    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
> roles:
>
>   - System.Messaging.dll
>   - Mono.Messaging.dll or whatever, that contains IMessagingProvider and so
> on.
>   - The actual implementation of IMessagingProvider.
>
> No functionality in System.Messaging would work without the last item, and
> when
> it is loaded by the runtime, it should not conflict with LGPL2-licensed
> runtime.
>
> Actually we cannot distribute your IMessagingProvider implementation (the
> one
> hosted at code.google.com) inside our mono source tarball because it
> contains
> pre-compiled dependency libraries and hence does not match current build
> design
> 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
> have
> to provide another package and source tarball just for this bridge
> implementation.
>
> Unlike NMS in ActiveMQ or AMQP implementation in RabbitMQ, this Qpid stuff
> is
> too rich and has a lot of external dependencies, which do not look suitable
> here.


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
>
>
Regards,
Michael Barker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080425/ccfd91d2/attachment-0001.html