[rabbitmq-discuss] Exchanges, Routing, and AMQP

[Kirk Wylie]

Also, John O'Hara piped up on the Blog post where I told everybody who
reads said drivel-filled-narcissistic-writing
(http://kirkwylie.blogspot.com/2008/10/amqp-exchanges-and-routing-thread-on.html)
that apparently this has all been resolved in the 1.0 draft, which I'm
QUITE eager to see.

Hopefully that will resolve this!

Kirk

On Tue, Oct 21, 2008 at 5:40 PM, Kirk Wylie <kirk at kirkwylie.com> wrote:
> Ben,
>
> On Mon, Oct 20, 2008 at 7:03 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
>> On Mon, Oct 20, 2008 at 4:01 PM, Kirk Wylie <kirk at kirkwylie.com> wrote:
>>> Personally, I believe that the spec should be changed so that
>>> exchanges are nothing other than producer-provided namespaces/groups
>>> of related messages, and consumers should bind to exchanges based on
>>> the semantics that they want.
>>
>> I think you may find resonance with some members of the WG on this
>> issue. However, moving the routing algorithm to the binding does have
>> a practical implication from an implementation perspective. This would
>> turn any routing decision into a linear scan of all of the bindings in
>> order to perform a match on the routing type :-( You would not be able
>> to exploit any type-based indexes.
>
> Well, no, actually, that's not true. That's only true of a naive
> implementation of a binding-based system. The RabbitMQ-based
> implementation where you're modelling all the primitive AMQP concepts
> as direct Erlang processes would definitely suffer from this problem,
> but I'm sure you could work out a system where invoking a binding
> dynamically modifies the routing table of the exchange.
>
>> This is true, but I think until AMQP goes 1.0, you should, IMHO,
>> prioritize design over backwards compatibility.
>
> Agreed completely.
>
>> I think it may not necessary be a good idea to de-characterize an
>> exchange to the extent that it merely represents a logical address. If
>> you were to do so, you would be automatically precluding semantics
>> that you could efficiency build into a custom exchange (e.g. an
>> exchange that delivers to a subset of the matching binding - for
>> example the shortest queue).
>
> Well, you're talking about a custom routing rule, and conflating that
> with an exchange. Custom routing rules are great, and orthogonal to
> Exchanges if you decouple exchanges from routing, which is what I'd
> really prefer.
>
>> Furthermore, you can bring the consumer driven-ness into the realm of
>> your app by having a convention that prevents a producer from
>> declaring exchanges - if the exchange doesn't exist, then the producer
>> will not be able to send messages to it.
>
> Then the "createExchange" call shouldn't be an assertion, it should
> check for a pre-defined configuration point.
>
> Remember, I'm concerned with badly written applications, where they
> might even tell you in documentation all the exchanges that they're
> using, but they're actually lying. This happens a lot sadly.
>
> Kirk
>