README.md in redis_failover-0.3.0 vs README.md in redis_failover-0.4.0

@@ -11,19 +11,19 @@
 master, and all reads go to one of the N configured slaves.
 
 This gem attempts to address both the server and client problems. A redis failover server runs as a background
 daemon and monitors all of your configured master/slave nodes. When the server starts up, it
 automatically discovers who is the master and who are the slaves. Watchers are setup for each of
-the redis nodes. As soon as a node is detected as being offline, it will be moved to an "unreachable" state.
+the redis nodes. As soon as a node is detected as being offline, it will be moved to an "unavailable" state.
 If the node that went offline was the master, then one of the slaves will be promoted as the new master.
 All existing slaves will be automatically reconfigured to point to the new master for replication.
-All nodes marked as unreachable will be periodically checked to see if they have been brought back online.
-If so, the newly reachable nodes will be configured as slaves and brought back into the list of live
+All nodes marked as unavailable will be periodically checked to see if they have been brought back online.
+If so, the newly available nodes will be configured as slaves and brought back into the list of live
 servers. Note that detection of a node going down should be nearly instantaneous, since the mechanism
 used to keep tabs on a node is via a blocking Redis BLPOP call (no polling). This call fails nearly
 immediately when the node actually goes offline. To avoid false positives (i.e., intermittent flaky
-network interruption), the server will only mark a node as unreachable if it fails to communicate with
+network interruption), the server will only mark a node as unavailable if it fails to communicate with
 it 3 times (this is configurable via --max-failures, see configuration options below).
 
 This gem provides a RedisFailover::Client wrapper that is master/slave aware. The client is configured
 with a single host/port pair that points to redis failover server. The client will automatically
 connect to the server to find out the current state of the world (i.e., who's the current master and
@@ -53,11 +53,11 @@
 
     Usage: redis_failover_server [OPTIONS]
         -P, --port port                  Server port
         -p, --password password          Redis password
         -n, --nodes nodes                Comma-separated redis host:port pairs
-            --max-failures count         Max failures before server marks node unreachable (default 3)
+            --max-failures count         Max failures before server marks node unavailable (default 3)
         -h, --help                       Display all options
 
 To start the server for a simple master/slave configuration, use the following:
 
     redis_failover_server -P 3000 -n localhost:6379,localhost:6380
@@ -84,9 +84,28 @@
      :password      - optional password for redis nodes
      :namespace     - optional namespace for redis nodes
      :logger        - optional logger override
      :retry_failure - indicate if failures should be retried (default true)
      :max_retries   - max retries for a failure (default 3)
+
+## Requirements
+
+redis_failover is actively tested against MRI 1.9.2/1.9.3. Other rubies may work, although I don't actively test against them. 1.8 is not supported.
+
+## Considerations
+
+Note that by default the failover server will mark slaves that are currently syncing with their master as "available" based on the configuration value set for "slave-serve-stale-data" in redis.conf. By default this value is set to "yes" in the configuration, which means that slaves still syncing with their master will be available for servicing read requests. If you don't want this behavior, just set "slave-serve-stale-data" to "no" in your redis.conf file.
+
+## Limitations
+
+The redis_failover gem currently has limitations. It currently does not gracefully handle network partitions. In cases where
+the network splits, it is possible that more than one master could exist until the failover server sees all of the nodes again.
+If the failover client gets split from the failover server, it's also possible that it could be talking to a stale master. This would get corrected once the client could successfully reach the failover server again to fetch the latest set of master/slave nodes. This is a limitation that I hope to address in a future release. The gem can not guarantee data consistencies until this is addressed.
+
+## TODO
+
+- Integrate with ZooKeeper for full reliability / data consistency.
+- Rework specs to work against a set of real Redis nodes as opposed to stubs.
 
 ## Resources
 
 To learn more about Redis master/slave replication, see the [Redis documentation](http://redis.io/topics/replication).