Trivial Text Messaging Protocol (working name)
Chatted with James and Max (no link for Max, don't really know him) about the trivial MQ wire protocol/format I'd talked about previously. We all rather agreed that it should be TCP based, despite the ease of implementation in a REST-y manner. We looked at BEEP, figuring we are reinventing stuff here (which we are) and BEEP is nice, and is optimizable, but it fails an important test, I cannot (easily) use the protocol by hand via netcat.
Current thought for messages is borrowing a lot from HTTP and SMTP -- they both work really well, after all =)
SEND ttmp://example.org/queue/EXAMPLE
session: 445a99490cdaed59122962bc1fd98051
reply-to: ttmp://example.org/session/445a99490cdaed59122962bc1fd98051
This is the message body^@
Should be pretty self explanatory. We dropped the xml encoding of the message, line-oriented is equally (or more) clear, less verbose, and less problematic for encoding XML as the message body.
Now, some stuff I haven't discussed, but have been thinking
about. This looks, smells, and even acts in many ways like SMTP. It
isn't. SMTP supports a lot of stuff I have no desire to
support. Also, TTMP (working name) requires a bunch of stuff you
could never retrofit onto SMTP now -- like requiring authentication,
period (the session is a key obtained from logging
in). I strongly suggest any implementation use SSL instead of raw
TCP in order to prevent replay attacks, but that is up to the
implementation).
"Automatic" reply-to has been dropped, a given connection will
always be given a receive-only queue it can listen on as part of the
login process, that is the recommended reply-to if you
need a private temporary queue. Implementations may delay actually
allocating any resources to said temporary queues until such a time
as a message is sent, so it is really just reserving a name.
The last interesting bit of the message format is the ^@ -- that is a null, ASCII-0. It is a specific known terminator and the one character disallowed in the message body. Yes, this will negatively impact performance compared to a message body size in the headers, but I cannot add up sizes when using netcat, so that option isn't there.
Probably need to figure out the commands next, and maybe provide some EBNF for them in order to start making it a properly formal spec. Feedback much appreciated!