Rails Talk at ApacheCon US 2005
Looks like my Rails talk was accepted for ApacheCon US in December. Woot!
0 writebacks [/tech] permanent link
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
Finally found a good name for the little streaming text oriented messaging protocol I've been working on =)
Stomp! (Bang optional)
(TTMP has always been a temporary (TMP, get it?) working name until the right one came along. Names are important in computing.)
More goodness to come!
0 writebacks [/src/stomp] permanent link
Been talking about the wicked greatness that is Ruby a lot, time to give Java some lovin'. Java offers a few things that you can certainly do in Ruby, but for now are actually a lot easier in Java. Basically Ruby has the general cases for Java's special cases -- sometimes the optimization for the special cases works best. Let's jam to some SOA goodness!
The plan:
Implement distributed Smalltalk style MVC:
Bennies include: Only state live in the app server is for the duration of whatever the command invoked, asynchronously, is operating on. All user-specific state can be stored in memory in the Javascript VM. 3rd party API for arbitrary alternate client is baked in. Problem domain for the application can be modeled solely in terms of the problem domain -- aspects handle any notifications needed. Etc.