AMQP Support

[ivanvanderbyl]

I have forked this project and begun work on AMQP (ruby-amqp and bunny) support. I was wondering if you have any design goals or plans with AMQP that I should be aware of? Before getting too involved.

https://github.com/ivanvanderbyl/qup/tree/feature/amqp-adapter

[copiousfreetime]

AMQP specific no, but general project approaches, yes.

I would prefer as much pure ruby as possible so that qup is as portable across as many ruby implementations and versions as possible, I'm not particularly happy that I had to use kestrel-client which depends on the memcached C library. I'll probably end up writing a pure ruby kestrel client before too long so that qup doesn't have a C extension in one of the adapters and supports the MONITOR command.

I also want the adapters, if possible, to be blocking adapters, or blocking with timeouts. I want to provide the broadest possible range of support, so the qup users can decide if and how they want to use threads/actors/eventloops etc. as part of their overall application instead of being constrained by the messaging system.

What this means for an AMQP adapter is I would prefer a bunny or carrot based adapter over a ruby-amqp adapter. Were you planning on multiple AMQP adapter implementations?

I see you have made a few other changes to your feature branch with respect to project structure and such. I have a few comments on that too.

All documentation is part of rdoc so should be in rdoc format, when rdoc 3.13 is released with markdown support, then I'll probably convert the top level docs to markdown so that they look better on github. For the time being though, they need to stay rdoc. Code documentation should be tomdoc.

I didn't see any 1.9 only features immediately, but just so you know, Qup will support 1.8 until ruby 1.8 itself is no longer supported (june 2013). For that reason, I'll be taking the coverage tools out of the gem development dependencies and they will only exist when the repo is checked out. I've added #4 to track this.

Bundler is a great tool, and it is not going to be a dev requirement of qup. I'll support its usage which is why I have the rake develop:using_bundler task to get that setup. I'll probably check in a Gemfile at some point. Along those lines, I don't plan on any .gemspec file existing in the repo, since I only consider released versions as stable. If folks want to use :path or :git urls in their Gemfiles for qup, they are more than welcome to do so in their own forks and then send pull requests if they would like to contribute.

As for the splitting out into lots of gems, I initially didn't want to do that, but it may be the best way for ease of use for people using qup.

Well that was a bit of a longer reply than I expected, I hope it doesn't turn you off contributing. I do want an amqp adapter in qup, I just haven't gotten around to it myself yet.

I'm definitely looking forward to your pull request :-).