default to tcp keepalive off

because that makes more sense, frankly
fixing accessibility/mutability issue

why in the hell did i leave the resource cache store exposed and
mutable? DON'T CODE DRUNK KIDS
internally using AbstractResource

to the outside world, AbstractResource isn't in the API, but to the
inside world, it definitely should be! this is happening now because I'm
trying to expose Resource information and the interface doesn't carry
the dependency information, which one must admit is TOTALLY INTERESTING
more exposed stuff that didn't need to be

just leaving all sorts of state all over the place in the resource
system! luckily i never seemed to be using it anywhere so reducing
visibility has been fairly cheap thus far
documentation

never really stated how to use this class
adding a way to display the resource cache

it's pretty d3 specific, actually.. but that's okay. for now
the resource cache inspector

hmmmm need like... builtins now.  the RCI is only used from my example
app.  basically works! and it's very helpful to understand the state of
the resource system.  gonna make it better, though.  much better
renaming the configuration environment

just config is fine
moving automatic scripts to the end of the body

also setting up the correct dependencies on the automatic scripts
not loading jasmine assets unless we have a spec to run

kinda small thing, but there's no reason to bother pulling them into
memory if we're not actually running a spec
using the MessagesResource

somehow i missed this before.  also setting up the dependency.  woo
making resources more inspectable

it's getting interesting.  and helpful! but i want it to be live and
therefore awesomer
okay the Sha1Resource is now for real.

it's been sitting there staring at me for like a year.  so i finished
it.  woo.  still needs something in the integration test validating it
but that shouldn't be too hard
checkpointing

the design is starting to make sense, at least.  but i'm not sure what
API i want anymore.  still.  have a set of scripts for now
using Guice correctly, and testing it

shouldn't throw exceptions out of type encounters, instead add errors to
the encounter so that provisioning can continue and all errors can be
accumulated.  Plus I wasn't verifying this before.  Whoops
documentation
not invoking Jasmine for the Jasmine scripts

the rabbit hole goes tooooo deep trying to test these using their own
runner.  they are integration tested, basically, and that must suffice,
and this way we don't keep trying to load them
refactorings to support sending server events to scripts

mainly just moving some pieces into the CodeGenHelper, and creating an
in-memory classpath for javassist to hold bytes for generated classes
since apparently, despite the documentation, it doesn't do that.  yay
documentation!

on the other hand, the script event stuff actually works, but that's not
in this commit because i'm still figuring out how to test it.
optimizing resource initialization

the directory tree was requiring that every single resource receive
every single ResourceLoaded event.  that is a nightmare waiting to
explode once this gets out of being for test deployments.  extracting
the logic into a helper allows for a single listener with smarter
registration semantics with the exponential time algorithm lying in
wait.

also, the correct behavior is now asserted in the integration test, to
ensure that the expected dependency structures are maintained in the
face of such goings on.  it's fairly basic, make sure the dependencies
are what are expected at each stage of the lifecycle
documentation