Adjusted adding mechanism to be better, maybe...
Handlers no longer know their path, just their subpaths.

Also added some consistancy things like a '/' at the end of all paths
and every path is lowercase.

 If you go to your browser and type a path in all upper case, it will
still find the correct path. This works for not putting a '/' at the end
of your path in the browser as well.
More documentation!
Merge branch 'path-tests' of github.com:dkuntz2/java-httpserver into path-tests-dk

Conflicts:
	handlers/HelloHandler.java
	httpserver/HTTPHandler.java
look, it works now
More documentation! MORE I SAY, MORE!

Most non-obvious methods have been Javadoc'd, but there's still a lack of
internal method documentation, explaining what's going on inside of
methods. While that's not horribly important, I think that because this is

  1.    An open source project we're putting together because Java's kinda
        lacking a really good RESTful server. And if it isn't lacking such
        a thing, it's lacking an open source one. And

  2.    We're doing some unnatural acts in the code, and there's a lot of
        metaprograming (on purpose, there really isn't another way to do
        things), and other concepts that aren't incredibly easy to figure out
        at first.

We should probably work on getting things nice for us and other people to
understand, both by writing good, meaningful comments (and possibly commit
messages, I'm not quite sure yet), and by keeping everything well formatted and
easy to read.

Basically, while there are some difficult concepts in here, I think a good goal
for us is to explain those concepts in a way that people who haven't been
exposed to them before can understand.
Tried making handling better...

It's getting there...
Merge branch 'path-tests' of github.com:dkuntz2/java-httpserver into path-tests-dk

Conflicts:
	handlers/HelloHandler.java
	httpserver/HTTPHandler.java
actually merged, because it wasn't real last time...
Merged with Don
Paths and variables work!!

They work pretty well and they even use the correct variables and
everything. It's much cleaner than what it was before as well.
Updated code to correct style, more documentation.

Updated most of the source to the correct style (which is currently correct only
in my head, but that's okay, we'll get the style guide up and running at
some point in the future (or is it futre?), but until that point, you're just
going to have to live with me arbitrarily making changes to your code in the
name of "style").

Also fixed up some documentation, and added some TODOs, which should be
addressed at some point. Probably tomorrow, I'm thinking tomorrow...
no vim, I don't want your swp files
CONTRIBUTING
The handler's now go to their relative paths like they should.

Before they went to the relative path sometimes when it was the default
handler (I think it was that way anyway), but other than that they still
had their key in the path. That is not the case anymore.
Switching to HTTPHandlerFactory setup / New Demo

Working on switching away from reflection for determining what kind of
HTTPHandler should be used, and using an HTTPHandlerFactory (which is an
abstract singleton factory, huzzah?) instead.

The idea behind this was discussed. Mostly it provides people with more control,
because the idea is that you just let everything be, and use our methods to make
things work. Well, you lose a good deal of control with the reflection setup
(you can't add extra stuff in your handler constructors is the big thing, which
would mean we wouldn't be able to use this with Storyteller, which is maybe the
whole goal, kinda), which makes it not the best.

As for the demo stuff, I just wanted to make the demo better.
forgot to remove
Well, my stuff works...
Variable checking exists.

If you pass in an `Integer` in a path that requests a `Float`, the
`howCorrect` method will return `0`.

Also added another handler called the addHandler which adds things.
MERGED?