README.md in lograge-0.0.3 vs README.md in lograge-0.0.4

@@ -5,10 +5,14 @@
 and, in the context of running multiple processes and servers, unreadable
 default logging output. Rails' default approach to log everything is great
 during development, it's terrible when running it in production. It pretty much
 renders Rails logs useless to me.
 
+Lograge is a work in progress. I appreciate constructive feedback and criticism.
+My main goal is to improve Rails' logging and to show people that they don't
+need to stick with its defaults anymore if they don't want to.
+
 Instead of trying solving the problem of having multiple lines per request by
 switching Rails' logger for something that outputs syslog lines or adds a
 request token, Lograge replaces Rails' request logging entirely, reducing the
 output per request to a single line with all the important information, removing
 all that clutter Rails likes to include and that gets mingled up so nicely when
@@ -49,14 +53,30 @@
 Enable it for the relevant environments, e.g. production:
 
 ```
 # config/environments/production.rb
 MyApp::Application.configure do
-  config.lograge.enabled = true 
+  config.lograge.enabled = true
 end
 ```
 
+You can also add a hook for own custom data
+
+```
+# config/environments/staging.rb
+MyApp::Application.configure do
+  config.lograge.enabled = true
+
+  # custom_options can be a lambda or hash
+  # if it's a lambda then it must return a hash
+  config.lograge.custom_options = lambda do |event|
+    # capture some specific timing values you are interested in
+    {:name => "value", :name => "%2f" % float}
+  end
+end
+```
+
 Done.
 
 **Internals**
 
 Thanks to the notification system that was introduced in Rails 3, replacing the
@@ -77,35 +97,55 @@
 
 While the LogSubscribers encapsulate most logging pretty nicely, there are still
 two lines that show up no matter what. The first line that's output for every
 Rails request, you know, this one:
 
+```
+Started GET "/" for 127.0.0.1 at 2012-03-12 17:10:10 +0100
+```
+
 And the verbose output coming from rack-cache:
 
+```
+cache: [GET /] miss
+```
+
 Both are independent of the LogSubscribers, and both need to be shut up using
 different means.
 
-For the first one, the starting line of every Rails request log, Lograge removes
-the `Rails::Rack::Logger` middleware from the stack. This may look like a drastic
-means, but all the middleware does is log that useless line, log exceptions, and
-create a request transaction id (Rails 3.2). A future version may replace with
-its own middleware, that simply removes the log line.
+For the first one, the starting line of every Rails request log, Lograge
+replaces code in `Rails::Rack::Logger` to remove that particular log line. It's
+not great, but it's just another unnecessary output and would still clutter the
+log files. Maybe a future version of Rails will make this log line an event as
+well.
 
 To remove rack-cache's output (which is only enabled if caching in Rails is
 enabled), Lograge disables verbosity for rack-cache, which is unfortunately
 enabled by default.
 
 There, a single line per request. Beautiful.
 
 **What it doesn't do**
 
+Lograge is opinionated, very opinionated. If the stuff below doesn't suit your
+needs, it may not be for you.
+
 Lograge removes ActionView logging, which also includes rendering times for
 partials. If you're into those, Lograge is probably not for you. In my honest
 opinion, those rendering times don't belong in the log file, they should be
 collected in a system like New Relic, Librato Metrics or some other metrics
 service that allows graphing rendering percentiles. I assume this for everything
 that represents a moving target. That kind of data is better off being
 visualized in graphs than dumped (and ignored) in a log file.
+
+Lograge doesn't yet log the request parameters. This is something I'm actively
+contemplating, mainly because I want to find a good way to include them, a way
+that fits in with the general spirit of the log output generated by Lograge.
+
+**Changes**
+
+* Add `custom_options` to allow adding custom key-value pairs at runtime (Adam
+  Cooper, https://github.com/adamcooper)
 
 **License**
 
 MIT. Code extracted from [Travis CI](http://travis-ci.org).
 (c) 2012 Mathias Meyer