On 06/01/2018 05:45 PM, Michael Bonnet wrote: > On Tue, May 29, 2018 at 12:51 PM, Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > >> Hi, >> >> On 05/29/2018 09:31 AM, Jeffrey Ollie wrote: >>> On Thu, May 24, 2018 at 11:16 AM, Aurelien Bompard < >>> abompard@xxxxxxxxxxxxxxxxx> 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[0]. 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 example). 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? -- Jeremy Cline XMPP: jeremy@xxxxxxxxxx IRC: jcline
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/LUF5PRIY2OFTCEW3ULW4NWDKTOWNEJIG/
