BERT supports binary data natively, you don't need to encode it like with JSON-RPC.

Thanks for the clarification

I wonder if they evaluated AMQP...

His first requirement is "extreme simplicity". That alone would disqualify AMQP. Just seeing the size of the AMQP spec makes me want to cry. I'm sure it's the right choice for some things, but most apps that need RPC or message passing don't need anything remotely as complex.

Rather than the spec (for message broker implementers, etc) I'd care more about the programming interface, toolchains, and features/performance. AMQP can be simple to use. And you can certainly send "simple" messages with it, they just get there reliably. The author asks us not to scream "NIH" so I will stop there - just did not see it as a potential tech examined and rejected in the BERT doc.

The problem is that this breaks down the moment your needs aren't met by one of the existing message brokers, and when that happens it really sucks to be tied to a massive protocol.

A reliable message broker is easy to write when your needs are simple. You can write one in a few hundred lines of code. If your needs are simple enough that they can be met by a simple protocol that can be implemented that easily, picking one means you know it's trivial to yank out your broker when it doesn't fit your needs, or you may find it easier to just write one targeting your specific needs from the outset.

As I said, I'm sure AMQP has it's uses. But personally the places where I've used message brokers the needs have been simple enough that it was a toss up whether it would be more work to write a custom broker vs. configuring and working around things that wasn't a perfect fit for us with existing brokers. My first Ruby project was a message broker, actually, and it was pretty much done in a day.

Building a simpler protocol (BERT-RPC or something with similar semantics) on top of a more complex one (AMQP, designed for complex pub-sub use cases) is sort-of backwards. It means you need to duplicate functionality that belongs at the lower layer, and drag along all kinds of extra baggage.

Instead, a message queue should ideally be built on top of a simpler RPC/message-passing protocol. One thing I dislike about AMQP and similar protocols is that they put too many aspects of the communication into one layer, making it harder to re-use portions of them for other purposes. I don't know if you've ever looked at the AMQP spec, but it's kind of a monster (a 280 page PDF file).

> duplicate functionality that belongs at the lower layer, and drag along all kinds of extra baggage

I'm just talking about sending messages not any kind of new protocol on top, for example http://code.google.com/p/py-amqplib/source/browse/demo/demo_...

There's of course some overhead vs. a simple BERT-RPC to set up a broker (you can set up simple ones fast...), but that should be weighed against the gains you get.

And note that my curiosity/confusion also comes about because we are talking about a technology with a reliable software stack and money behind it (for example, RabbitMQ written in Erlang) vs. building a protocol from scratch. The situation is different if you are looking at equally mature technologies.