support stomp header for work queue and add support to subscribe active-mq temp-queue

[ellyxc]

Stomp adapter implementation didn't allow us to specify stomp headers. I added this ability in pull and push queue (Work queue pattern). Additionally I added new functionality to subscribe active-mq temporary queue.

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[sam-github]

The point of strong-mq is to have identical interfaces across various mq backends. The pro of this is you can swap the backend without changing your code. The con is that you don't get access to features that don't work on all the backends.

This change makes stomp-specific APIs, and active-mq specific APIs. If you want to write code that only works with a specific mq backends, why not just use the stomp or active mq packages directly?

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[vshabelnyk]

+1 - it was needed in our project as well. Please merge!

[sam-github]

Could @ellyxc @RootMale and @francois-montmasson-efg please comment on my questions in #21 (comment).

The purpose of this module was to provide an _identical_ interface across AMQP, STOMP, and an internal to node in-memory MQ I threw together. I haven't heard of anybody using it for that, and can't think of another reason to use it.

Making a STOMP specific API in strong-mq makes me wonder why you don't just use STOMP directly.

I can sink time into maintaining this if I see some purpose to it... but ATM its more likely to become officially deprecated, and put up for adoption.

[ellyxc]

@sam-github I never work with AMQP, so i don't know if it's header or temporary queue. Currently my company uses stomp header and temporary queue. The idea of using strong-mq instead of stomp directly is to have the ability to replace stomp to another with minimum code modification.