Fwd: [stomp-dev] Fwd: I want my MOM

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: [stomp-dev] Fwd: I want my MOM


Begin forwarded message:

From: "Zed A. Shaw" <[hidden email]>
Date: October 28, 2005 11:48:04 PM EDT
To: Hiram Chirino <[hidden email]>
Subject: Re: [stomp-dev] Fwd: I want my MOM

Yeah, sure go ahead and repost.  I'm watching STOMP very closely so
maybe I'll subscribe soon.  One thing about your comment below:

Why does it have to be all or nothing?  What you state as a difficulty
with a binary only pre-sized protocol like OpenWire might be more to do
with the complexity of a binary protocol and not so much a pre-size
problem.  By just sprinkling the two minimal size elements (header
size/content length) you get a reasonable midpoint.  You get the speed
and safety of presized that is still a simple to implement non-binary

And, as I mentioned in my original post, I actually implemented this
protocol as a 10 minute hack in Ruby.  It's not difficult at all.

I'll try to clean the code up and post it someplace for you folks to
review.  Sometimes working code just works better than an e-mail.


On Fri, 28 Oct 2005 17:55:32 -0400
Hiram Chirino <[hidden email]> wrote:

I agree with all the above and and that's the way the OpenWire  
protocol (the native ActiveMQ protocol) is implemented!  But the  
premise of stomp is based on the exact opposite premiss of the  
OpenWire protocol.  The OpenWire protocol aims to be the most binary  
efficient protocol in both speed and size that can be used for a  
messaging server.  It does:
  * the message pre-sizeing (since it makes it easy to do IO polling/ 
  * every thing is streamed in binary, no ASCII to decimal parsing.
  * bit streaming so that all the booleans in the stream can back  
packed in smaller bit stream
  * value caching so that repeat values don't need to be sent 2
times down the wire.

And even though we code generate both a Java and C client for the  
above protocol, it's still very hard to implement new language  
clients since there's so much going on.  The point of stomp was keep  
it as simple as possible, ignore all performance concerns, so that  
new clients can be implemented in minutes not days.