Document JSON syncing and fix README typos

CHANGES.md

@@ -1,7 +1,7 @@
 # Rojo Change Log
 
 ## Current Master (0.4.0)
-* Began protocol version 1, which shifts more responsibility onto the server
+* Protocol version 1, which shifts more responsibility onto the server
 	* This is a **major breaking** change!
 	* The server now has a content of 'filter plugins', which transform data at various stages in the pipeline
 	* The server now exposes Roblox instance objects instead of file contents, which lines up with how `rojo pack` will work, and paves the way for more robust syncing.

DESIGN.md

@@ -36,4 +36,14 @@ The plan is to have several built-in plugins that can be rearranged/configured i
 	* User passes a binary name (like `moonc`) that modifies file contents
 
 ## Roblox Studio Plugin
-With the protocol version 1 change, the Roblox Studio plugin got a lot simpler. Notably, the plugin doesn't need to be aware of anything about the filesystem's semantics, which is super handy.
+With the protocol version 1 change, the Roblox Studio plugin got a lot simpler. Notably, the plugin doesn't need to be aware of anything about the filesystem's semantics, which is super handy.
+
+## Bi-directional syncing
+Quenty laid out a good way to handle bi-directional syncing.
+
+When receiving a change from the plugin:
+1. Hash the new contents of the file, store it in a map from routes to hashes
+2. Write the new file contents to the filesystem
+3. Later down the line, receive a change event from the filesystem watcher
+4. When receiving a change, if the item is in the hash map, read it and hash those contents
+5. If the hash matches the last noted hash, discard the change, else continue as normal

README.md

@@ -26,10 +26,11 @@ Rojo has a number of desirable features *right now*:
 
 * Work on scripts from the filesystem, in your favorite editor
 * Version your place, library, or plugin using Git or another VCS
+* Sync JSON-format models from the filesystem into your game
 
-Soon, Rojo will be able to:
+Later this year, Rojo will be able to:
 
-* Sync Roblox objects (including models) bi-directionally between the filesystem and Roblox Studio
+* Sync rbxmx-format Roblox models bi-directionally between the filesystem and Roblox Studio
 * Create installation scripts for libraries to be used in standalone places
 	* Similar to [rbxpacker](https://github.com/LPGhatguy/rbxpacker), another one of my projects
 * Add strongly-versioned dependencies to your project
@@ -103,7 +104,7 @@ For example, if you want to map your `src` directory to an object named `My Cool
 
 The `path` parameter is relative to the project file.
 
-The `target` starts at `game` and crawls down the tree. If any objects don't exist along the way, they'll be created as `Folder` instances.
+The `target` parameter is a path to a Roblox object to link the partition to. It starts at `game` and crawls down the tree. If any objects don't exist along the way, they'll be created as `Folder` instances.
 
 Run `rojo serve` in the directory containing this project, then press the "Sync In" or "Toggle Polling" buttons in the Roblox Studio plugin to move code into your game.
 
@@ -117,6 +118,7 @@ Creation of Roblox instances follows a simple set of rules. The first rule that
 | `*.server.lua` | `Script`       | `Source` will contain the file's contents |
 | `*.client.lua` | `LocalScript`  | `Source` will contain the file's contents |
 | `*.lua`        | `ModuleScript` | `Source` will contain the file's contents |
+| `*.model.json` | *Varies*         | See [this file](test-project/src/hello.model.json) for an example model |
 | `*`            | `StringValue`  | `Value` will contain the file's contents  |
 
 Any folders on the filesystem will turn into `Folder` objects unless they contain a file named `init.lua`, `init.server.lua`, or `init.client.lua`. Following the convention of Lua, those objects will instead be whatever the `init` file would turn into.