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

[Michael Barker]

On Fri, Apr 25, 2008 at 10:30 AM, Atsushi Eno <atsushi at ximian.com> wrote:

> Oops, sorrry, I was dead for couple of days and after that it has dropped
> from my mind for a while.


No problem, thanks for responding.


> Here's my quick survey:
>
> - 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.


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

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

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?

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

Regards,
Michael Barker.


>
>
> Michael Barker wrote:
>
>> Hi,
>>
>> As I mentioned a couple of days ago I have a 0.0.1 version of a bridge
>> between Mono and QPid.  I have placed the code and a patch that adds an SPI
>> to Mono on google code.  http://code.google.com/p/mono-qpid/
>>
>> There is quite a bit missing from the implementation, but basic sending
>> and receiving with XML and Binary formatting works.
>>
>> Regards,
>> Michael Barker.
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080425/e92caa11/attachment.html