[rabbitmq-discuss] A new exchange type

[Ben Hood]

Alistair,

On Wed, Jan 28, 2009 at 3:30 PM, Alister Morton
<Alister.Morton at tradition.com> wrote:
> In order that last value caching can work, you'd need to be able to ask the broker to notify you (a publisher) whenever a
> queue was connected to an exchange that you'd flagged as needing last value caching, in order that the last value can
> be pushed again. But this last value must only be pushed to the newly connecting queue, so it would have to have
> some kind of flags attached to it to indicate that it was a refresh and was not to be passed to queues that had already
> seen it. While this is possible, I think it could add as much complexity as adding a new exchange type.

In general, I'm in favor of layered approaches - it keeps the broker
simpler, means less maintenance and means that the community can more
easily mash Rabbit up rather having to wait for the snail-paced Rabbit
engineering team. I think that the criterion for judging whether
functionality should be in the broker or get implemented as a
porcelain should be based on whether doing it in the broker would be
significantly more efficient than application layer code. This may the
case if the broker can exploit knowledge that higher level code is not
privy to.

Dmitriy's idea of exposing AMQP events in userland via a pub/sub model
has merits - it may even up the playing field between what the broker
is able to do and what application code can do.

My suggestion of how to further develop this line of thought is write
a small POC text that would play through the mechanics of each use
case for both variants (i.e. a POC for a new exchange and one for an
AMQP event model) - this is incidentally what we may end up having to
anyway, if we get around to implementing this feature.

Ben