On 06/01/2018 05:45 PM, Michael Bonnet wrote:
On Tue, May 29, 2018 at 12:51 PM, Jeremy Cline
> On 05/29/2018 09:31 AM, Jeffrey Ollie wrote:
>> On Thu, May 24, 2018 at 11:16 AM, Aurelien Bompard <
>> abompard(a)fedoraproject.org> wrote:
>>> What do you think of this proposal? Any blind spots?
>> Not that I disagree, but please add/expand a section as to why AMQP (and
>> RabbitMQ) was chosen over other messaging technologies.
> Thanks for the feedback, I've added a small section. It is, perhaps,
> a little wishy-washy. I don't want to give the impression that we
> couldn't implement this with a different messaging protocol or a
> different broker. We definitely could. AMQP has short-comings, to be
> sure, but the RabbitMQ extensions (mainly pulisher acks) cover the most
> important ones in my opinion.
> I did some research, but I'd definitely welcome feedback on protocols
> and brokers. I've read all or nearly all of the AMQP 0.9, ZeroMQ, and
> STOMP protocols, and I skimmed through the MQTT protocol, but I've not
> looked closely at the AMQP 1.0 protocol and I'm by no means a message
> protocol expert.
I think moving to a broker-based architecture is a great idea! Your
document does a great job explaining the advantages it brings, and it could
help increase the adoption of event-based workflows.
Regarding protocols, my preference would be for STOMP. It's has very wide
support, with libraries in pretty much every language, and being entirely
text-based makes it *much* easier to debug than other protocols. The
message delivery semantics are well-defined, and the protocol spec has the
nice property of being readable in one sitting. Some brokers provide the
ability to translate between protocols, so it may not be difficult to
support more than one, but I would suggest STOMP as the reference protocol.
I had a hard time justifying choosing STOMP over AMQP because most
brokers just map the other protocol they focus on onto STOMP. It's true
the the spec is short, but it leaves a lot up to individual
implementations as far as I can tell (like how topic matching works, for
While debuggability is important, I'm not certain we'll ever need to dig
into the wire protocol. In the unlikely event that we need to, I'd go
about it the same way (e.g. tcpdump/wireshark) and Wireshark knows how
to parse the AMQP protocol. Based on my super simple test (capture a
single message being published) it seems very easy to inspect. Have you
had a different experience here?