Hmm, got a fair chunk of feedback in the mere seven hours since I talked about the name change telling me not to do it! Mostly it boiled down to "TTMP sounds like a protocol, Stomp doesn't." Though most folks put it more eloquently.
I was shocked, I didn't realize people felt strongly already. Okay, chance for feedback =)
My thought is that Stomp is more memorable and less likely to be confused with smtp, http, etc in the ears of folks who think "r freaking clue?" when they hear RFC. As was pointed out to me, sounding like a protocol name is not a bad thing for a protocol, on the other hand. Other names considered included tomp (which does a nice stomp for the ssl wrapped version), stmp (which is far too close to smtp for my taste), and Johan (my generic name, like Bob).
The best benefit of stuff still in development is that it is malleable. Seriously, some feedback is appreciated and I'll hold the ax off on the name change for a bit -- names are important. I won't go through months of wiki voting (a la echo/atom) for a current developer community of four though =)
On the other hand, is it good when the unsolicited feedback "the name change is a bad idea" outweighs unsolicited technically feedback 3:1? Either we're doing something right with the protocol, or... ? Regardless, I love unsolicited feedback, period, as it means people care enough to step forward!
1 writebacks [/src/ttmp] permanent link
Mon, 22 Aug 2005Ian Holsman has written a ttmp client for perl. Woot!
0 writebacks [/src/ttmp] permanent link
Sun, 21 Aug 2005
TTMP Protocol Specification 1.0 Release Candidate 1
Well, I promised a cleaned up TTMP wire protocol before the end of the weekend, and here it is. I also updated the ruby client to be more useful. A tutorial and expanded docs are coming, but the main change is that you add listeners on specific subscriptions and for receipts instead of using a single listener for all messages.
The ActiveMQ implementation supports the 1.0 Release Candidate 1 protocol spec.
Meanwhile, Aaron is sitting next to me hooking a more recent build of ActiveMQ (which supports TTMP) into Geronimo =)
4 writebacks [/src/ttmp] permanent link
Wed, 10 Aug 2005I beat on the ttmp wire format for ActiveMQ some more, connecting and sending messages work (see transcript!):
brianm@kite:~$ nc -v localhost 8899
localhost [127.0.0.1] 8899 (?) open
CONNECT
login: brian
passcode: wombat
^@
CONNECTED
session:ID:kite.local-63748-1123682509041-1:0
^C punt!
brianm@kite:~$ nc -v localhost 8899
localhost [127.0.0.1] 8899 (?) : Connection refused
brianm@kite:~$ nc -v localhost 8899
localhost [127.0.0.1] 8899 (?) open
CONNECT
login: brian
passcode: wombats
^@
CONNECTED
session:ID:kite.local-63760-1123682587710-1:0
SEND
destination: /queue/example
This is an example message, nothing fancy, an unfortunately... we won't see the result =(^@
^C punt!
brianm@kite:~$
Unfrotunately, while subscribing ~works (the consumer is pushed to activemq) I cannot seem to get ActiveMQ to actually feed messages into the protocol handler =( I am doing something wrong (as I can move messages using other protocols (and crossing from ttmp to ActiveMQ native is easy -- I am sending via ttmp and receiving via ActiveMQ's default tcp protocol -- tracing highly asynchronous, multi-threaded (and worse, select/ring-buffer style) code isn't easy.
Anyway, current working doc for the ttmp protocol will remain posted online.
1 writebacks [/src/ttmp] permanent link
Mon, 08 Aug 2005Beat on TTMP some this evening, after doing a bunch of work on a top-secret project this morning. The best part is that I have no idea which project is more fun =) Yea!
Anyway, current state of the TTMP connection handshake:
Client sends a CONNECT frame:
CONNECT
login: [login name]
passcode: [passcode]
^@
Please excuse the use of [foo] instead of <foo> for required things. I am too lazy to escape them =)
Okay, so client sends that, server will either reply with an error indicating a failed login:
ERROR
message: [error message]
^@
Or a CONNECTED
CONNECTED
session: [session id]
^@
Yeah! You are connected. The login handshake has been implemented
in ActiveMQ. It's a bit hacky because TTMP is much less chatty than the JMS spec, so the WireFormat implementation has to pretend there is more traffic than there really, but that is an implementation detail =)
I am not sure about requiring the session on every
frame now that it is definately a connection-oriented protocol. The
socket is certainly trackable, and requiring the session implies you
can change sessions, which isn't something I think I want. Will muck
around some, but am thinking hard of dropping that.