Read config from YAML file
Add AMQP connection URI
First pass at adding Travis
Update README.md
Setup 2-way AMQP and Invoca pub/sub simulators

The Broker will need to listen for AMQP messages as well as publishing
them. This is implemented for now using two separate queues, although
I'll need to read more about AMQP to see if there's a more semantic way.
I'm not wild about the queue names either.

Two scripts are added to `invoca/` to simulate sending/receiving AMQP
messages from the Invoca API end.
Convert Broker to module and move Channels to SocketServer

The Broker is never actually instantiated as a class, so we can clean
things up by turning it into a module instead.

Also, Channels are only needed within the SocketServer so they are moved
there.

A remaining TODO is to set up infrastructure in the SocketServer to
handle incoming AMQP messages (using the existing subscription in the
broker)
Add strong_parameters

We'll need to validate message from Invoca's API somehow, and
strong_parameters from Rails is a great way to do that.

Adding the gem was strangely difficult, and caused a number of
dependency resolution issues. For now, it appears that requiring
strong_parameters __before__ anything else works, but after causes a
load error. Not sure why, hopefully this won't come back to bite us
later.
Add dependency to forked version of StrongParameters

Getting Strong Parameters to work outside of Rails turns out to be a
pretty painful exercise. Unbeknownst to me, the rails/strong_parameters
gem appears solely to exist as a shim for Rails 3 projects, and not as
an extraction of the functionality. I ended up forking strong_parameters,
and pasting in the code currently in the Rails 4 source tree. This is
an exercise in pain and not at all a nice solution, but at least it
works for now.
Typo fix
Add dynamic dispatch for event types

The event dictionary isn't finalized yet and so we'll probably need to
change json schema / signatures. Regardless, this adds in the basic
infrastructure we'll need for dynamic method dispatch.
Fix incorrectly named context
#and_return doesn't take a block apparently
Attempt to bridge Broker-Invoca / Broker-Client sides

The Broker maintains a connection to Invoca via AMQP, and connections to
browser clients via websockets. However, for anything useful to be
accomplished, these two sides must be able to talk to each other, a task
which is surprisingly difficult.

Goliath performs some interesting tricks by default. For example, the
default behavior is to start the server in an `at_exit` handler, so all
you have to do is define your server class and it will automatically run
and "just work". As a consequence of this, the actual server object is
constructed internally within Goliath and it is nigh impossible to get a
programmatic handle to it from anywhere outside. The ramificiations of
this are as follows:

Goliath communicates with browser clients through *instance* methods defined
on the server class, e.g. `on_open`, etc. The Broker-Invoca side of things
communicates with the server using *class* methods, e.g.
`Broker::SocketServer.handle_call_start`. However, since the server
instance is only referenced internally within Goliath, there is no way
to bridge these two things!

I can think of virtually no solution to this problem without modifying
the internals of Goliath. So we'll do the next best thing - rip out the
necessary lines from the Goliath source and paste them into our own so
we can save a reference to the server instance!

Just kidding, that's not the next best thing, this code is garbage. It'll
have to do for now until I can come up with a better solution.
Fix Goliath hackery madness

Commit #1aa1ba5 added in some gnarly hacks in an attempt to get a handle
to the Goliath server object. This was needed because the Broker-Invoca
and Broker-Client interfaces used class/instance methods respectively
and it was difficult to bridge those.

On reflection, there was no need to use class methods at all. It was
done that way because the AMQP queue subscription was being set in the
Broker, as opposed to the socket server. This commit modifies the code
to set up the subscription at the Goliath instance level, so when
messages come in we can call all the instance methods we please.
Use config.yml.example file
Revert "Use config.yml.example file"

This reverts commit e9a3653f12e8991ec1a63f1be25017faf93a92ad.
Add console simulator

This adds a basic customized console we can use to simulate events
coming from Invoca. Usage:

$ rake broker:console
>  Invoca.call_start
>
> Invoca.call_stop

If everything is set up properly, the messages should go through the
Broker and get broadcast to listening browsers!
More robust event routing

This solidifies the Invoca-Broker and Broker-Client interactions and
event handlers a little more. There's more to be done, but this is the
gist of it.

The code is all one giant lump in socket_server.rb, which makes me sad.
It'd be nice to split everything into modules at the very least.
Simulator doesn't need EventMachine
Add Goliath startup code from @colindkelley

We were running into issues splitting up Goliath code due to the fact
that we had no instance handle to call methods on. This adds code from
Colin that will enable us to keep a reference to a server object and
split things up (to be added in future commits)