[Mono-dev] Fwd: [PATCH] System.Messaging using AMQP (RabbitMQ)

[Atsushi Eno]

Hi Michael,

Michael Barker wrote:
> Hi,
> 
> I have updated the bug report
> (https://bugzilla.novell.com/show_bug.cgi?id=432471) to include a
> first cut of MessageEnumerators.  It does seem to work, originally I
> though that an AMQP Ack would acknowledge all messages up to that
> point, but that does not seem to be the case, so I can implement the
> System.Messaging behaviour reasonably well.

Looks like (at least) Mono.Messaging.RabbitMQ/MessageFactory.cs is
missing. Can you please check missing stuff in the patch (probably
new files) ?

>> Well, I'm rather afraid of having Mono.Messaging base API dependent
>> on Rabbit (by "dependent" I don't mean that Mono.Messaging.dll has
>> reference to Mono.Messaging.RabbitMQ.dll). AMQP solution might not
>> be chosen if it lacks significant functionality, but that does not
>> mean it is no-go. If Rabbit based implementation does not work here,
>> I rather assume nothing would work fine here ;)
> 
> I would be useful if you could describe what you mean by dependent?
> I'm assuming that you're referring to the design of the API.  I've
> tried hard to avoid designing Mono.Messaging based on the RabbitMQ
> bindings.  The majority of it is direct delegation from the
> System.Messaging library (expect for the parts that don't need to
> happen in Messaging implementation, e.g. formatting), so the
> Mono.Messaging is more dependent on that library.

Sometimes we see System.Messaging bridge API, well, SPI, as to be
actually dependent (or premised) on the message queue implementation.
For example, if we return an array of Message (in bridge) to be used
in MessageEnumerator (sys.messaging), it may not be very efficient
for some queue systems that return IEnumerator of Message (it does
not have to iterate all messages just to create an array).

As long as the common SPI is direct delegation, it should be fine.

> Also I think that Mono.Messaging should be considered only as an SPI,
> not an API.  Anyone writing an application requiring a brand new

OK (I didn't bother to differentiate API from SPI ;)

> RE: AMQP, If its of any use here are a list of the main features and
> how they can be supported:
> 
> Supported easily through the standard:
> - Basic Messaging Send/Receive
> - Message Listeners
> - Transactions
> 
> Supported with a couple jumps through hoops:
> - Peek() (may be better supported through queue browsers later on)
> - Message Enumerators
> 
> Supported only with custom extensions to the server:
> - {Receive,Peek}By{Id,CorrelationId,..}
> 
> Supported only with later potential protocol updates:
> - Queue discovery

Thanks, that's a nice list of the features to be (or not to be)
supported :) For the time being, Peek and retrieval by IDs can
be left unimplemented. There would be a couple of ways to provide
queue discovery emulation through configuration, dummy management
queue or something else (apart from the queue system itself).

I think it'd be good way to create a branch for your implementation
in svn and let other people help hacking other implementations
(such as Win32API one, as I suggested earlier).

Atsushi Eno