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

[Atsushi Eno]

Hello,

(You might want to read it from bottom to top :p)

Michael Barker wrote:
>
>     - You cannot add any public extra stuff (such as Mono.Messaging.*
>     classes)
>      in System.Messaging.dll. You have to create another assembly (such as
>      Mono.Messaging.dll) and use it together with System.Messaging.dll. 
>
>
> That's interesting, I looked at System.Data initially, which included 
> Mainsoft namespace classes, so I thought adding a different namespace 
> into the same namespace would be okay.  I am happy to change that.

That's simple: we can add extra namespaces. We cannot add public types 
in an extra namespace.
 
>
>       It is sort of mess, as either
>
>      - System.Messaging.dll depends on your extra assembly and hence yours
>       cannot use any types in System.Messaging.dll (e.g. you cannot define
>       IQueue.Deliver), or 
>
>
> This is probably the easiest, but is adding a compile time dependency 
> for System.Messaging.dll on another assembly acceptable?  I assume we 
> shouldn't be adding additional public classes to the System.* namespaces.
Adding a compile-time dependency for Sys.Messaging.dll is acceptable (we 
already
do that, such as Mono.Security.dll for System.dll and System.Security.dll).
Note that assemblies, namespaces and types are all different here.

It may look the easiest before you write code, but other choices may be 
still
easier in reality. You should feel free to switch between those ideas at 
anytime :)

>       - your extra assembly depends on System.Messaging.dll and hence any
>       types in yours inside System.Messaging.dll must be used through some
>       reflection foo, or
>      - you have to run cyclic build between those two assemblies (we do it
>       for System.dll, System.Configuration.dll and System.Xml.dll,
>     which is
>       a mess).
>
>     - At least MessageQueue.Create() should be implemented (otherwise
>     it is not
>      practically functional as System.Messaging.dll). It would have to
>     be done
>      by some configuration support to indicate one IMessagingProvider,
>     and it
>      must not be dependent on System.Configuration.dll which is 2.0-only.
>
>     - It would provide only simple part of Sys.Messaging functionality
>     (it would
>      apply to any JMS/AMQP based solution). We could still go with your
>      bridge implementation for a while as a compromised solution though. 
>
>
> That's true, however the AMQP spec is not yet finished.  I believe 
> that there will be browsing and selector support in some of the later 
> revisions.  This will mean that the majority of the System.Messaging 
> functionality is covered (including MessageQueue.Peek and 
> MessageQueue.ReceiveById).  The parts that probably won't be covered 
> would be some of the specifics around the additional system queues 
> (e.g. journal queues).  Although AMQP does support sophisticated 
> routing rules so it may be possible to emulate some of those features.
Oh, that's great news to me :) I was indeed wondering how Peek() could 
be supported by those JMS-based messaging systems (even with AMQP, as 
most of AMQP services are implemented in Java). I also guess that some 
of those special queues can be
implemented by some supporting queues or databases.

> 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.

>     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 ;-)

Atsushi Eno