Hi Andrew,

Thanks for taking the time to provide a detailed response.  Much
appreciated.

I'll provide some comments below:

On May 10, 12:34 pm, "Andrew Kuklewicz" <kooks...@gmail.com> wrote:

I am totally happy to have the stomp gem use any of my patches and
pull them into the code.  My 'fork' is not so much to take the project
in a different direction, it is just the terminology used freely in
the Git/GiHub context where forks are encouraged, but used to feed
changes back to the master.  I have found github to be an excellent
tool for getting additional work done by others and feeding that back
to the master since the barrier to entry for submitting changes is so
very low (no commit privs needed, just fork and go, and then send pull
requests for changes.

My git repo is actually able to be actively connected to both the SVN
master which I would pull your changes from, and then merge them into
my branch which is what I would push to GitHub.  So if you or others
commit changes I can get those onto Git and keep everything in synch.

Or even better :-)  You can fork my git repo, and push the work onto
github and we can merge our git repos easily.  Or I'll give you commit
access to my git repo directly.  Once all the changes are cool in this
working area we can bundle it all up in a patchset and commit it all
back to the SVN trunk for official release.

All this being said, if there is opposition to this approach, I am
fine with providing someone with patches agains the svn repo for any
changes that I have done and closing down the GitHub version if there
is confusion.  I think I made clear the intentions in the readme on
the site though.

Cool.

The reason I was setting up the structure for having tests in Rspec is
because:

a) It is a much better testing framework IMHO. :-)
b) It has a built in mocking and stubbing framework so it will be
possible to build tests that:
    - Exercise only the class being tested (e.g. the Client and mock/
stub any calls to the Connection class).
   - Use mocks/stubs to mock the connection and responses from the
external stomp server.  This removes the dependency on having a
message queue running in order to run the tests (and allows you to
mock the expected response that the stomp spec says should be
returned, and not what different implementations of the spec actually
return.
  - Rspec provides mechanisms to keep the testing code more DRY.
Notice I was able to remove two of the test unit files completely
since they three files contained all of the same exact tests with only
the setup of the connection being different.  This makes maintenance
really hard.  Check out my start on Rspec where you'll see I was able
to duplicate the functionality and can run different setups against
the same suite of test cases.  You can see that in
http://github.com/grempe/stomp/tree/master/spec/client_spec.rb where I
specify it should 'it_should_behave_like "standard Client"'.

To clarify what I would like to be able to do.  I want to be able to
make a call to @connection.somemethod and have it return the next
message on the specified queue.  If there is a message, give it to me
and close the connection.  If there is no message return nil.  As I
look at the comments in the code this is what poll seems to offer
(comments say : # Return a pending message if one is available,
otherwise return nil.).  However, if there are no messages on the
queue, poll blocks since its using the same receive method.  No?  My
expected behavior would wrap the process of opening a connection,
getting a message if avail, and then disconnecting.  While this may
not be as efficient as a thread which is listening and not always
opening and tearing down connections it is useful in some cases.

Thanks again for the detailed response.  Actually much of what you
said should be included in the rdoc comments in the code to make it
clearer for newcomers how some of the code is expected to work.
Perhaps I'll drop some of your comments in as a starting point if you
don't mind. :-)

Cheers.

Glenn