[bunny-amqp-devel] [ANN] Bunny 0.5.4 Release Candidate

[Bunny AMQP client mailing list]

I'm in the process of putting together the next release - v0.5.4 - of
Bunny. The 'next_release' branch on GitHub (http://github.com/celldee/
bunny) has the changes that I am suggesting go into the next release.
Now is the time to have your say before I bake the new Bunny. You can
get a copy by cloning the repository and switching to the
next_release branch like so -

1. Go to the directory that you want to copy Bunny to
2. git clone git://github.com/celldee/bunny.git
3. git checkout next_release

The following wiki page contains the details of the changes that are
slated for the next release -

http://wiki.github.com/celldee/bunny/future-changes

If there are things you want changed, re-considered, explained or
added let me know and I will try to accommodate you.

Regards,

Chris Duncan
_______________________________________________
bunny-amqp-devel mailing list
bunny-am...@rubyforge.org
http://rubyforge.org/mailman/listinfo/bunny-amqp-devel

[Bunny AMQP client mailing list]

Hi Chris,

Thanks for the continued support and enhancements!

I haven't looked at the new branch but I'm assuming that pop will still return :queue_empty when appropriate, as it currently does, right?  If so, then it sounds like I can immediately add "msg = msg[:payload] if msg.respond_to?(:key?)" after I make sure msg != :queue_empty, to make sure my code will be compatible when the new version is released.  Does this sound reasonable?

--Mark

On Mon, Sep 14, 2009 at 5:02 AM, Bunny AMQP client mailing list <bunny-am...@rubyforge.org> wrote:

I'm in the process of putting together the next release - v0.5.4 - of Bunny. The 'next_release' branch on GitHub (http://github.com/celldee/bunny) has the changes that I am suggesting go into the next release. Now is the time to have your say before I bake the new Bunny. You can get a copy by cloning the repository and switching to the next_release branch like so -

[Bunny AMQP client mailing list]

Hi Mark,

On Sep 15, 2:08 am, Bunny AMQP client mailing list <bunny-amqp-

de...@rubyforge.org> wrote:
> Hi Chris,
> Thanks for the continued support and enhancements!
>
> I haven't looked at the new branch but I'm assuming that pop will still
> return :queue_empty when appropriate, as it currently does, right?  If so,
> then it sounds like I can immediately add "msg = msg[:payload] if
> msg.respond_to?(:key?)" after I make sure msg != :queue_empty, to make sure
> my code will be compatible when the new version is released.  Does this
> sound reasonable?
>

Yes you could do that, however, I propose that Queue#pop always
returns a hash unless you provide a block, in which case the hash will
be passed to the block.

When you pop on an empty queue a hash will still be returned but it
will contain { :header => nil, :payload
=> :queue_empty, :delivery_details => nil }. So what you would have to
do, assuming that you are only interested in the message payload, is
get the payload first and then test for :queue_empty. Something like
the following should work in the case you put forward -

msg = q.pop
msg = msg.respond_to?(:key?) ? msg[:payload] : msg

if msg != :queue_empty
process message ...
end

HTH and thanks for your encouragement.

Regards,

Chris

[Bunny AMQP client mailing list]

Thanks Chris, keeping the return value as a hash and putting :queue_empty in :payload makes sense.  I'll make the appropriate changes in anticipation of this.

--Mark