changelog in magic_mirror-0.1.1 vs changelog in magic_mirror-0.1.2

@@ -3,13 +3,19 @@
 future.
 
 	- Test against port in use problem.
 
   - How do you tell the host gem to just 'listen for commands' and idle there?
-    (so the reverse usage of trtl)
-    possible do a .join() on the sinatra thread?
+    > 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
@@ -18,17 +24,59 @@
         it performs a reset
 
   - Think of other popular uses for rendering...
   - secure by making servers listen only on localhost
 
-  - Hide the STDOUT from starting the servers and print the
-    address of the listening http server in a pretty manor that links
+  - 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
 
-  - Write wrapper for TkcOval, btw...
+      * 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 **