[rabbitmq-discuss] Exchanges, Routing, and AMQP

[Alexis Richardson]

All,

Some ideas for simplifying the exchange-binding model to address (NPI)
issues raised by eg Kirk, are being looked at for AMQP 1.0.  Although
we as a community are talking about code - and this is good - please
keep the use cases coming as people working on the spec will benefit
from them and may jump in.

Peter, in relation to routing patterns for headers or other content,
or indeed generalised active queries: the aim is to keep the core use
cases compact so that a reader can grok the spec in one or two reads.
Extensibility and pluggability and layering are hence the get-out for
enabling more cases while keeping a simple core.

What is wrong with extensible protocols?  Implementors may effectively
'fork' them by specialising in different add-ons.  But then these are
not ubiquitous (or even prevalent) and so do not get as much use.  So
there really is an incentive for implementors to make sure the *right*
core is there for widespread adoption - favouring a simple core.

In the case of RabbitMQ extensions a neat trick is to use the embedded
client to filter and relay in a 'smart' way, and process messages
without an extra network hop.  This is good.

alexis


On Tue, Nov 11, 2008 at 11:35 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Peter,
>
> On Tue, Nov 11, 2008 at 4:42 AM, Peter Silva <Peter.A.Silva at gmail.com> wrote:
>> I found the FAQ explanation that though fanout/topic/direct are successive
>> specializations, having it in the spec permits broker side optimizations
>> unconvincing.  If people keep bringing it up, then maybe it's a sign that
>> the spec is doing something that violates the principle of least surprise.
>
> In general you may have a point, if after closer inspection the
> ultimate reason for surprise is counterintuitive for many people.
>
>> The broker could just perform optimizations on the bindings in place and not
>> clutter up the standard.  The really general thing to do is the header type,
>> using a matching syntax.
>
> Fine, but it's one thing to specify something and another to actually
> implement it. Whilst probably not being rocket science I don't think
> that implementing that the headers exchange in a scalable fashion is
> as straight forward as you infer.
>
>> Nor do I grasp why an exchange is anything special.   The exchange name
>> could easily be the first element of the routing key to apply the pattern
>> to.  One can bind to all exchanges or a pattern of exchanges, rather than
>> having to specify each exchange individually.
>
> This discussion (as an extension to the thread Kirk started) is going
> on too long. If defering the routing type to the bindings is as
> trivial as you maintain, then please enlighten me with a proof of
> concept written in a language of your choice. It would have not have
> to be AMQP specific, just something that shows the basr fundamental
> routing lookup mechanism based on the data structures you are
> proposing.
>
> Code speaks louder than words and I would love to be proven wrong.
>
>> On the other hand,
>> going through long lists of regular expression evaluations can kill
>> performance.
>
> :-)
>
>> Does anyone else use complicated routing like us?  Does it sound like
>> something that AMQP might get to later?
>
> Regex exchanges have been discussed before and it would be reasonably
> straight forward to implement, it would proabably look like the
> current topic exchange. As you indicate, unless you something really
> funky with your index, this would incur a linear scan of the bindings.
>
> Ben
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>