path didn't work out as planned
fix debug msg
add state.js to repo

It implements a state machine that will allow us to
disentangle the url management in the service object.
Add URI state machine with possible states

state.js works by calling the state() function, with a
state declaration inside of it.

Each of the properties in this object is going to be
either a function, or another state declaration object
wrapped in a call to state().

In this commit, we add 4 states that this object will
be able to find itself in.
Add implimentations of the .get and .set methods.

When you have a property that is only a function, it
will be the method implementation used when the
object is in that state, or any of it's child
substates.

In this case, a call to uri.get() will reach the
same function, no matter the state.

With an object in the 'Initial' state, a call
to uri.set(3000) will reach the method defined
in that state.
Add listen and forward methods.

We are adding noops to the root state (ie: not in the child states),
because we only need an implementation in the Initial state.

Future calls to these functions will no longer result in any
change of the object.
Conditionally change states based on input

You can access the state representation of any stateful object
using the this.state() accessor.

It has a number of methods that affect/read the object's state,
and is the lynchpin to the whole state.js library.

We are using one of the 3 mechanisms to change to another
state. They are:

1. `this.state().change('TargetState')`
2. `this.state().go('TargetState')`
3. `this.state('-> TargetState')`
Start tests: turning objects stateful

Any javascript object can now be turned into an implementation
of the state machine we built.

It will now have the this.state() accessor attached to it.
Tests: Retrieving the currect state's name

You can use this.state().name to get the current name
of the state.

As you see here, it went to 'Initial' because we tagged
the state as that in the definition.

If we didn't do that, the state would have been '.', which
is where the get/listen and forward methods are defined.
Tests: Changing between states

Use all three possible methods to switch between
the available states.
Tests: check if the automatic transition happens.

This is where we would pick up if our state machine
implementation is broken.

One of the best things about them is that we are
able to test them easily outside of the scope
of the rest of our apps.
I realized connection is a more appropriate name.
Add connection mode and status machines.

To be able to manage the state of each service correctly, we are
also going to need to orchestrate whether we are forwarding/listening,
and whether the machine has been stopped or started.

We will coordinate all this using events, as each of the states,
and the machine as a whole acts as event emitters.
Rename all the files for consistency.

Also switched to using the same object constructor
pattern for all the state machine.

Where I had initially intended to extend the service
class, it became obvious that there was more than
one state machine at play here.
Introducing transition events and guards

I am now making use of the state machine's mechanisms to track
changes.

When you change state from one to the other, it will fire transition
events, that are also bound to functions on the instance.

Similarly it has a set of guards, that can stop the onbject from
leaving the current state, or entering a next one.

we make use of this to do custom processing on the input when
we arrive to the new state, and stop the state from ever getting
invalid.
URL's now provably correct through state machine.

This is the problem I set out to resolve by rewriting this
using state.js. When isolated from the rest of the application,
I was able to write these tests and ensure that the url's
are always correctly generated.

It took me longer to do since I was carefully capturing
these commits, and writing the commentary.

Still, It has allowed me to reduce the possible corner cases, and
work on just this little piece until it works Right.

next, we rewrite the rest of the application to build
off this new base.
Listen on 0.0.0.0, add listen tests
Final refactoring. Vastly simplified and works!
Merge pull request #3 from wayfin/state-js

Refactor services as a state machine with state.js