3 ms·
I'm the author of original Stomp protocol. Much of what changed in 1.1 and 1.2 came from people smarter than me, so blame me for the ugly and them for the good.
by brianm 10y ago
I'm the author of original Stomp protocol. Much of what changed in 1.1 and 1.2 came from people smarter than me, so blame me for the ugly and them for the good.
Why text? Because I wanted to be able to debug it with netcat, implement minimal but acceptable clients by inspection of the wire, etc. More importantly, I wanted anyone else to be able to do the same.
At the time, AMQP was just starting to get steam, and it was a gross, exceptionally difficult to implement, binary protocol. (AMQP has evolved a huge amount from those early forms.) In looking for something better, the ease of using SMTP and HTTP and the fact that I often did do them directly in netcat to debug or understand behavior, decided the direction.
Sure, SMTP, HTTP, etc., style protocols can be wonky at times, but the number of times I have in fact done them by hand is very high. Avoiding the need to break out Wireshark, and write a message packer on the fly as Wireshark only supports reading what comes across, makes using it, when you don't have a client yet, great. I've had people implement clients, from learning about the protocol to using the working client, during a half hour talk about Stomp. They can do this because it bootstraps on knowledge of HTTP, and text is easy on humans (if more involved for computers).
This ease of examination and manipulation is the same reason that JSON is (approximately) infinitely more prevalent than protobuf, thrift, avro, messagepack, or even smile (which is the exact json semantics, but way more compact and fast to parse). The desperate perl hacker of XML fame is a very real thing, don't ignore the implementation and debug affordances provided by text-based protocols.
- viraptor 10y ago> but the number of times I have in fact done them by hand is very high How many times did you do them correctly and according to spec? And how many times did you just rely on servers accepting things that aren't terribly incorrect? Maybe you actually followed RFCs, I don't know... But from my experience with looking at short code that pretends to do HTTP/SMTP, they often work by accident and a new encoding or some special characters thrown into the message break them pretty bad :( I spent a few years working with SIP, which way too many companies treat as "hey, it looks like HTTP, and is simple!" and follow with their own interpretation of how things should work. It's awful.
- weberc2 10y agoWould you consider putting this rationale on the Stomp webpage? I spent quite a while trying to understand what problem this solved before finding your comment.
- mike_hock 10y agoNo, you cannot implement a conforming client or server of any protocol by inspecting the wire. How do you know there aren't other cases that you're supposed to handle that simply didn't happen to occur in the sessions that you sniffed? HTTP is the prime example of why being a text protocol doesn't make it simpler.
- _wmd 10y agoHey Brian, Just wanted to say thanks for Stomp, protocols that are simple enough to be easily reimplemented are definitely underrated. The Python story for Stomp is not so great, especially working with Twisted (e.g. there I think stompest is the best option available). On profiling I discovered this module's parser was horrendous, contributing something like 30% to my runtime. Had it been some binary protocol with a complex spec, I might have spent days reimplementing it, but producing a simple and fast parser took only an hour or two, and now my problem is solved. For others complaining about Stomp, my reimplementation is 116 lines of perfectly testable code, and for a problem domain as simple as wrapping messages up in a few verbs, this is how it should be. (Will be releasing tinystomp.py at some point, but it needs a little tidying up and documenting first!)