> I was really happy to see Brian's support behind this - I was feeling a bit
> protective on his behalf, as this was his baby, but with is support, I am
> totally for what you are doing/have done. To be honest, most of my interest
> in the gem to date has been to make it work for active messaging and fix
> bugs, not to go to the lengths you are now; I applaud your efforts.

> A few comments below:

> On Sun, May 11, 2008 at 6:37 PM, Glenn Rempe <glenn.re...@gmail.com>
> wrote:

>> 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.

> I have no personal opposition to what you have done. I reacted a bit
> conservatively only as Brian had not weighed in yet, and I wanted to make
> sure he was cool with this.

> I'll try to get my changes in using your git rather than svn - I am not
> using git for any of my own projects yet, so it will be a good excuse to get
> more familiar.

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

> I like consistency - if all the tests are moving to specs, I am cool with
> it.
> I agree that mocking is essential in testing code like this.

>> 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.

> The "_receive" private method is passed in a connection, and tries once to
> get a response frame, then returns nil if there is none.
> The "receive" public method tries to establish a connection by calling
> "socket", then uses "_receive" to try once to get a message.
> Where "receive" can block is when the connection needs to be
> (re)established, and the connection attribute reliable == true.

> If the connection is good, it will therefore try to call "_receive" once
> only, and so do what you are looking for.
> If the connection is nil, it will try once to connect if reliable=false,
> otherwise it will retry until it gets a connection - and therefore blocks.
> So reliable=false essentially makes "receive" always behave in the
> non-blocking way that you describe.

> Well, that is a slight gloss - "_receive" does block, but only in order to
> make sure that the entirety of a frame is read of the connection at once -
> again, you want it to synchronize around this, as you don't want competing
> threads to each get a piece of a single frame.  So that blocking I assume
> you are not worried about - more it is the blocking retry logic that seems
> to be your (understandable) concern.

> One of the changes I have been working on is cleaning up the way recieve
> and _receive are used (mostly because I found a bug in the retry logic, but
> also to make it better and clearer), so this is an area that I believe needs
> work anyway.

> I am generally not a huge fan of the existing retry logic, which we are
> touching on a bit here.
> You either have no retries if you have reliable=false, or it retries
> infinitely (or until success) if reliable=true - I would rather have retry
> counts with a configurable max retry count - what do you think?

> 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?

> First off - I don't use poll, and neither does the Client that comes with
> stomp gem; it is an unneeded wrapper on receive as far as I am concerned.
> It really ought to be deprecated, removed, or repurposed to do something
> useful.  The only thing it does is return nil if there is not a connection
> already, whereas receive will open a connection if there is none. Never had
> a reason to use this.

> So yeah, that comment is not exactly true, as described above:
> If reliable=false, then that is how both poll and receive will behave -
> returning nil if there is no message or it can't make a connection
> If reliable=true, it keeps retrying until it connects, and then keeps
> retrying until it returns a message.

>>  My
>> expected behavior would wrap the process of opening a connection,
>> getting a message if avail, and then disconnecting.

> Set reliable=false, and that is what calling receive will do, except it
> does not automatically disconnect.
> We can add another method perhaps that also does he disconnect, but there
> should be some method such as receive that does not do this, as
> disconnecting will get rid of all your existing subscriptions, and you
> really don't always want to do that - activemessaging relies on the fact
> that once you have connected and subscribed, it can simply use receive to
> get messages off without having the overhead of reconnecting and
> resubscribing.

>> 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.

> In some cases, I agree, and in those cases, we can have a different method,
> or finer grained options for retry logic.  ActiveMessaging is built using
> the assumption of a single connection with subscriptions to receive messages
> as they come in, and not closing and resubscribing all the time.

> 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. :-)

> Of course not - I've spent alot of time in this code, for better or worse.
> I hope my long-windedness can be slightly helpful to the new guard.

> -Andrew