Make Redmon a mountable Rack app

[romanbsd]

This change allows using Redmon alongside another Rack application, such as Rails.
It required to refactor the config handling.
I also updated the README for the usage examples.

[steelThread]

Thanks @romanbsd it works like a champ.

[romanbsd]

It's possible to start the worker automatically, using something like this:

require 'redmon/app'
require 'redmon/worker'

module Redmon
  class Railtie < Rails::Railtie
    config.before_configuration do
      if EM.reactor_running?
        Worker.new.run!
      else
        fork do
          trap('INT') { EM.stop }
          trap('TERM') { EM.stop }
          EM.run { Worker.new.run! }
        end
      end
    end
  end
end

The downside is that it'll use a bit more memory, as the rails already loads some part of the framework until this point.
I tried to run it in a thread, but then the Thin fails to start.

[steelThread]

@romanbsd can you elaborate a bit more please? I understand the Railtie hook but the memory (heap?) part I'm a little fuzzy on. Is it enough of a concern that I should consider refactoring the worker to use something like a Celluloid timer. Although it seems a little strange to mix an evented and threaded solution together when running outside of a Rails env. Also, is it bad practice for gems to start a reactor or spawn a thread when being used inside a Rails app?

Perhaps it would be possible to mixin a strategy (EM or threaded) into the Worker. Thoughts?

Thanks again for the input here.

[romanbsd]

I don't think that a refactoring of the worker is needed. IMHO, the best possible solution would be to hack into the running app after it's started, so the same EM reactor as used by the "thin" webserver is utilized and there's no wasted memory (for another process). But I don't think that it's possible without a monkey patch to thin.
The proper way with a Railtie would be using a config.after_configuration (rather than the before_configuration, as I wrote before), as it loads the files in the config/initializers, but this way even more memory will be wasted. In any case, this is something can you can put in the wiki for the further consideration, so if one is not concerned with some wasted memory, then it's a viable solution.

Also, is it bad practice for gems to start a reactor or spawn a thread when being used inside a Rails app?<<
it's not a bad practice, but some caution should be taken.