Fwd: [PATCH] System.Messaging using AMQP (RabbitMQ)
Forgot to CC the list.
---------- Forwarded message ----------
From: Michael Barker <mike <at> middlesoft.co.uk>
Date: Sun, Oct 12, 2008 at 5:46 PM
Subject: Re: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ)
To: Atsushi Eno <atsushi <at> ximian.com>
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.
> 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.
Also I think that Mono.Messaging should be considered only as an SPI,
not an API. Anyone writing an application requiring a brand new
application should either use System.Messaging or the messaging API
for the bus that are interested in using. That way we will only have
a single client of Mono.Messaging (i.e. System.Messaging) making it
reasonably easy to change as required, assuming that most of the
implementations of Mono.Messaging are included in the mono build.
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
If you have some good ideas about how System.Messaging should be
implemented, send them through.
Regards,
Michael Barker.
RSS Feed