changelog in magic_mirror-0.1.2 vs changelog in magic_mirror-0.1.3

- old
+ new

@@ -1,8 +1,6 @@ ** 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, @@ -13,70 +11,24 @@ 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 + > Solution: Make ports random? + > Solution: Make 1 port, but make things accessible as /roots/myRoot - - 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 + - secure by making servers listen only on localhost for websockets - * 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 **