Hi Glenn -

I just got your two messages about this git repo for a fork of the stomp gem
(I'm also on the stomp lists).
Glad to see more interest in stomp for ruby/rails.

I'm a bit confused why it was necessary to fork the project, and I hope it
does not becomes confusing for users.
When I had a number of bug fixes and changes for the gem, I submitted
patches and quickly found myself with commit rights.

Is there a reason you didn't want to submit patches to the existing gem
repo?
I am watching the store and actively work on and use the gem, and would have
been happy to help get your code committed, and I'm pretty such Brian would
be happy to have more contributers as well.

There are a number of changes to the stomp gem I have been working on lately
that fix some errors in the existing retry logic.
I am close to committing these to the gem trunk; I wonder how we can
coordinate active development on the gem with your fork of the code?

That said, if there is good stuff that comes out of your efforts, I would be
happy to help you get your changes into the official stomp gem repository.

I have a few other specific responses in context below:

The current gem doesn't use or depend on rspec; I respect that this is how
you like to work, but I would think it would be more appropriate to offer
test unit classes, as that is what the gem uses now, and otherwise you end
up with a mix of units and specs, and that's awkward.

The way the gem works now is that when you make a request, it blocks until
that request has been sent to the broker.
Is what you want to be able to do the send, but then immediately move on,
regardless of if the request has to be retried, or can even be sent right
away?  If so, it sounds like all you want is to use a different thread to do
the send, such as putting the send in the block for a Thread.new.

Or, is what you mean a way to get a _response_ to a request where listening
for the response is not blocking?
This to me sounds like a contradiction - if it's synchronous, it means you
are waiting for the response, which means it is blocking, or you are
building into your logic on the main execution thread to check back at
various points in the program flow to see if there is a response, which is a
hard/impossible thing to contain in a method call.  All the API could
provide for that is the equivalent of the private _receive method which
looks for a new message once then returns.

Poll works as I use it in a13g, perhaps it depends what you are trying to do
with it, or how you expect it to work?
What are you expecting?

Stomp as a protocol is designed so that you subscribe to destinations, and
the broker will then push messages to you over your open connection, but
that means some thread has to be listening/polling on that open connection
with some frequency to receive the messages.  So there you go, that's what
poll and receive do.

Receive loops checking to see if there is new incoming IO on the tcp port,
and once it gets a stomp frame, returns.  The _receive message tries once,
and then returns, so all receive does is call this in a loop till something
comes back.  Is what you want what _receive does, where it looks for a
message once and then quits, so it is not blocking?

Poll is just a synchronizing wrapper to make sure you don't have more than
one thread simultaneously trying to read the next message from off the
connection (imagine how ugly that could get, if we get 2 threads competing
to get IO off the connection, and end up with a single message read in
pieces by different threads).

I guess I just don't understand how you expect this all to work where some
thread isn't taken up busy trying to listen for incoming IO.

The Client class in the stomp gem starts up a listen thread to receive
messages on initialize, so it is not blocking the main execute thread.  In
your main code you then register listener blocks when you subscribe that
will get called back asynchronously when your a message is received.

All you need to do is instantiate the Client, and use that to
This is the same approach in active messaging, where threads are started to
listen for messages.
Did you have another approach in mind?

If you don't want it to block, but you do want to listen for and then handle
messages whenever they arrive, that means you either need another thread, or
have breaks in the processing of the main thread to comeback and look for
incoming messages and handle them.

Anyway, let me know if I have misunderstood, and I look forward to your
contributions to stomp and messaging,

- Andrew Kuklewicz

Happy coding!

--
Andrew Kuklewicz