** 0.0.x **
  TODO:  List off what features you'll be including at some point in the
future.

	- Test against port in use problem.

  - How do you tell the host gem to just 'listen for commands' and idle there?
    > Call @magic_mirror.gaze_into to start event machine,
      create a defered faye client,
      make a subscription with said client
      then block with EM.run

      When a message is published to the subscribed channel, ruby can
      respond accordingly, with full access to the gem and ruby landscape...
      but ppl shouldn't directly eval the strings coming in over httpPost...

  - limitation:  Can only have one rendering display at a time *per computer*
      > Solution: Clean up the output and make ports random

  - Bug:  If faye server goes offline for a second, and misses commands, then comes back online,
    the command_cache variable will be out of sync with that of the server
      > Solutions:  Javascript Function periodically checks in to see the
        md5 checksum of server's command_cache and if the browser's is out of date
        it performs a reset

  - Think of other popular uses for rendering...
  - secure by making servers listen only on localhost

  - I noticed some missing parts to the tree...
    > Oh... right when you load the page, you'll get
        [command_cache] - [changes to command_cache since page load innitated]
      so a small gap in commands will exist...
        SOLUTION

      * Architecturally:  add an index number to each message sent over faye
      * Client-wise: Calculate
        [Index of first faye message] - [length of the command cache] = [gap]
      * request the gap from the server on receipt of first message from faye /gap?command_cache=95&first_faye=100



Currently:

  - The tree example takes forever to draw
    > Cache commands before sending through websockets:
      cache websockets commands and wait 0.1 seconds between each
      message sent...
      ... it's also just a hell of a lot of data...

    > Compress the command_cache: if the commands can be condensed so they
      take up fewer characters, performance will improve dramatically.
      *
      *

    > Dynamically build the tree function in javascript and reduce the command
      to 1 function definition plus an invocation...

    > What if command_cache SVG data instead of function calls?

  - The javascript chokes up... possibly because it's iterating over the command cache,
    and also responding to the websocket requests at the same time?

  - Use webworker??

  - Small discrepencies in bigish trtl lines in the tree example


  - Hmmm.... why don't I steam the command_cache over websockets?
    > The reason this is good is that it allows the client to get the data
      in incriments and then deal with the data, and then wait for more.
      This way the data never exceedes more than several kilobytes in memory...

  - EFFICIENTLY TRANSFER THE COMMAND_CACHE ARRAY:
    * embedded in html

    * embedded in html, but split into chunks!!! after each chunk is finished and
      processed/ deleted, the next chunk is gotten to until all the chunks are
      deleted!!!!!!!  !!!!!!!!!!!!!!!!!!!!

Finished:

** 0.1.1 **

  - Added command_cache#reset
	- Silenced booting of servers and added own boot message


** 0.1.0 **

	- Changed API to Minimizing magic_mirror commands needed on the host gem

** 0.0.2 **
  - got websockets online
  - Setup command_cache
  - Setup javascript for drawing to canvas

** 0.0.1 **
  - Release failed because the Trtl was missing dependencies