Merge pull request #3 from NodeRedis/v.2.0

v.2.0

.gitignore

@@ -2,3 +2,4 @@ logs
 *.log
 coverage
 node_modules
+.idea

.npmignore

@@ -0,0 +1,12 @@
+# IntelliJ project files
+.idea
+*.iml
+out
+gen
+
+# Unrelevant files and folders
+benchmark
+coverage
+test
+.travis.yml
+.gitignore

.travis.yml

@@ -12,7 +12,7 @@ node_js:
   - "0.10"
   - "0.12"
   - "4"
-  - "5"
+  - "6"
 install:
   - npm install
   - npm install hiredis

README.md

@@ -1,12 +1,11 @@
 [![Build Status](https://travis-ci.org/NodeRedis/node-redis-parser.png?branch=master)](https://travis-ci.org/NodeRedis/node-redis-parser)
 [![Code Climate](https://codeclimate.com/github/NodeRedis/node-redis-parser/badges/gpa.svg)](https://codeclimate.com/github/NodeRedis/node-redis-parser)
 [![Test Coverage](https://codeclimate.com/github/NodeRedis/node-redis-parser/badges/coverage.svg)](https://codeclimate.com/github/NodeRedis/node-redis-parser/coverage)
+[![js-standard-style](https://img.shields.io/badge/code%20style-standard-brightgreen.svg)](http://standardjs.com/)
 
 # redis-parser
 
-A high performance redis parser solution built for [node_redis](https://github.com/NodeRedis/node_redis) and [ioredis](https://github.com/ioredis/luin).
-
-Generally all [RESP](http://redis.io/topics/protocol) data will be properly parsed by the parser.
+A high performance javascript redis parser built for [node_redis](https://github.com/NodeRedis/node_redis) and [ioredis](https://github.com/luin/ioredis). Parses all [RESP](http://redis.io/topics/protocol) data.
 
 ## Install
 
@@ -21,7 +20,7 @@ npm install redis-parser
 ```js
 var Parser = require('redis-parser');
 
-new Parser(options);
+var myParser = new Parser(options);
 ```
 
 ### Possible options
@@ -30,8 +29,6 @@ new Parser(options);
 * `returnError`: *function*; mandatory
 * `returnFatalError`: *function*; optional, defaults to the returnError function
 * `returnBuffers`: *boolean*; optional, defaults to false
-* `name`: *'javascript'|'hiredis'|'auto'|null*; optional, defaults to hiredis and falls back to the js parser if not available or if the stringNumbers option is choosen. Setting this to 'auto' or null is going to automatically determine what parser is available and chooses that one.
-* `stringNumbers`: *boolean*; optional, defaults to false. This is only available for the javascript parser at the moment!
 
 ### Example
 
@@ -55,8 +52,7 @@ var parser = new Parser({
     },
     returnFatalError: function (err) {
         lib.returnFatalError(err);
-    },
-    name: 'auto' // This returns either the hiredis or the js parser instance depending on what's available
+    }
 });
 
 Library.prototype.streamHandler = function () {
@@ -70,7 +66,7 @@ You do not have to use the returnFatalError function. Fatal errors will be retur
 
 And if you want to return buffers instead of strings, you can do this by adding the `returnBuffers` option.
 
-If you handle big numbers, you should pass the `stringNumbers` option. That case numbers above 2^53 can be handled properly without reduced precision.
+Big numbers that are too large for JS are automatically stringified.
 
 ```js
 // Same functions as in the first example
@@ -82,44 +78,24 @@ var parser = new Parser({
     returnError: function(err) {
         lib.returnError(err);
     },
-    name: 'javascript', // Use the Javascript parser
-    stringNumbers: true, // Return all numbers as string instead of a js number
     returnBuffers: true // All strings are returned as buffer e.g. <Buffer 48 65 6c 6c 6f>
 });
 
 // The streamHandler as above
 ```
 
-## Further info
-
-The [hiredis](https://github.com/redis/hiredis) parser is still the fasted parser for
-Node.js and therefor used as default in redis-parser if the hiredis parser is available.
-
-Otherwise the pure js NodeRedis parser is choosen that is almost as fast as the
-hiredis parser besides some situations in which it'll be a bit slower.
-
 ## Protocol errors
 
-To handle protocol errors (this is very unlikely to happen) gracefuly you should add the returnFatalError option, reject any still running command (they might have been processed properly but the reply is just wrong), destroy the socket and reconnect.
-Otherwise a chunk might still contain partial data of a following command that was already processed properly but answered in the same chunk as the command that resulted in the protocol error.
+To handle protocol errors (this is very unlikely to happen) gracefully you should add the returnFatalError option, reject any still running command (they might have been processed properly but the reply is just wrong), destroy the socket and reconnect. Note that while doing this no new command may be added, so all new commands have to be buffered in the meantime, otherwise a chunk might still contain partial data of a following command that was already processed properly but answered in the same chunk as the command that resulted in the protocol error.
 
 ## Contribute
 
-The js parser is already optimized but there are likely further optimizations possible.
-Besides running the tests you'll also have to run the change at least against the node_redis benchmark suite and post the improvement in the PR.
-If you want to write a own parser benchmark, that would also be great!
+The parser is highly optimized but there may still be further optimizations possible.
 
 ```
 npm install
 npm test
-
-# Run node_redis benchmark (let's guess you cloned node_redis in another folder)
-cd ../redis
-npm install
-npm run benchmark parser=javascript > old.log
-# Replace the changed parser in the node_modules
-npm run benchmark parser=javascript > new.log
-node benchmarks/diff_multi_bench_output.js old.log new.log > improvement.log
+npm run benchmark
 ```
 
 ## License