notes about the docs

docs/design.md

 ## Overview
 
+**This document is out of date, and probably inconsistent. Current focus is on MVP, which has [it's own doc](mvp.md).**
+
 Dgraph is a distributed graph serving system, meant to be deployed in production,
 and tackle user queries in real time. The aim of the system is to run complicated
 joins by minimizing network calls required, and hence to keep end-to-end latency

docs/example.md

@@ -58,5 +58,5 @@ It can be split sharded to fit on multiple machines,
 just like Bigtable sharding works. This would mean a few additional RPCs, but
 still no where near as many as would be required by existing datastores.
 
-This system would allow infinite scalability, and yet production level latencies,
+This system would allow vast scalability, and yet production level latencies,
 to support running complicated queries requiring deep joins.

docs/mvp.md

@@ -36,7 +36,8 @@ Had considered Cap'n Proto before, but Flatbuffers team provides better Go suppo
 - For this version, stick to doing everything on a single server. Possibly still
 using TCP layer, to avoid complexities later.
 - Possibly use a simple go mutex library for txn locking.
-- Use UUID as entity id.
+- Use uint64 as entity id.
+- Support [GraphQL](https://facebook.github.io/graphql/): Facebook's new Graph Query Language.
 - Provide sorting in this version.
 
 ## Concepts / Technologies Skipped
@@ -82,6 +83,12 @@ Replica | Replica is defined as a non-leading copy of the shard after RAFT elect
 - One mutex lock per shard.
 - One single server, serving all shards.
 
+## Posting List
+- TODO: Write about how posting list reads and updates work. Possibly in another doc.
+
+## GraphQL
+- TODO: Write about what features are supported in GraphQL. Possibly in another doc.
+
 ## Write
 - Convert the query into individual instructions with posting lists.
 - Acquire write locks over all the posting lists.