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

[Atsushi Eno]

Hello,

Michael Barker wrote:
>      Thanks a lot for the updated implementation since April :) I had
> 
>     a look at the patch, and noticed that some essential stuff such as
>     MessageQueue.GetEnumerator() and MessageEnumerator are left
>     unimplemented. 
> 
> I've just had a look at the MessageEnumerator API and I'm not sure if it 
> can be implemented using AMQP as I don't think that its possible to 
> selectively remove messages from a queue (except with selectors, but 
> I'll get to that).  I'll try prototype it, but if it can't be 
> implemented do you think that an AMQP solution would be a no go?

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

>      BTW do you know if AMQP/Rabbit is going to support message peek
> 
>     and receive-by-id functionality (in some milestones), as you
>     mentioned in the early discussion ?
>     http://www.mail-archive.com/mono-devel-list <at> lists.ximian.com/msg16731.htm <http://www.mail-archive.com/mono-devel-list%20%3Cat%3E%20lists.ximian.com/msg16731.html> 
> 
> I had a chat with one of the standards committee members at a conference 
> around the end of April.  Selectors (to support ReceiveById) are 
> unlikely to be part of the standard, although there was a message on the 
> RabbitMQ list indicating that they'll probably add a server extension 
> (that's compatible with Apache QPid) to support it.  Queue browsers are 
> being considered, but peek functionality can be fudged by not 
> acknowleding messages.  The other area where there is a mismatch is 
> queue discovery, AMQP uses a declare model, i.e. all queues exist, but 
> its not possible to find what they're called.  Queue discovery is being 
> considered for a future revision too.

OK. If Rabbit .NET binding supports such extensions, you could simply
use them. The binding does not have to be limited to AMQP (still might
be better to have Rabbit/Qpid bindings based on AMQP binding based on
Mono.Messaging though).

Atsushi Eno