README.md in routemaster-drain-2.4.4 vs README.md in routemaster-drain-2.5.0

@@ -197,21 +197,32 @@
 
 response = @cache.fget('https://example.com/widgets/123')
 puts response.body.id
 ```
 
-In this example, is your app was notified by Routemaster about Widget #123, the
+In this example, if your app was notified by Routemaster about Widget #123, the
 cache will be very likely to be hit; and it will be invalidated automatically
 whenever the drain gets notified about a change on that widget.
 
 Note that `Cache#fget` is a future, so you can efficiently query many resources
 and have any `HTTP GET` requests (and cache queries) happen in parallel.
 
 See
 [rubydoc](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Cache)
 for more details on `Cache`.
 
+### Expire Cache data for all notified resources
+
+You may wish to maintain a coherent cache but don't need the cache to be warmed
+before you process incoming events. In that case, use the cache as detailed above
+but swap the `Caching` drain out for `CachingBusting`
+
+```ruby
+require 'routemaster/drain/machine'
+$app = Routemaster::Drain::CachingBusting.new
+```
+
 ## HTTP Client
 The Drain is using a Faraday http client for communication between services. The client
 comes with a convenient caching mechanism as a default and supports custom response materialization.
 The Drain itself has the concept of "HATEOAS"(see below) response that provides a common way of addressing resources.
 
@@ -275,14 +286,15 @@
 
 ## Internals
 
 The more elaborate drains are built with two components which can also be used
 independently,
-[`Dirty::Map`](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Dirty/Map)
-and
-[`Dirty::Filter`](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Dirty/Filter).
+[`Dirty::Map`](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Dirty/Map),
+[`Dirty::Filter`](http://rubydoc.info/github/deliveroo/routemaster-drain/Routemaster/Dirty/Filter) and
+[`Middleware::Siphon`](http://www.rubydoc.info/github/deliveroo/routemaster-drain/master/Routemaster/Middleware/Siphon).
 
+
 ### Dirty map
 
 A dirty map collects entities that have been created, updated, or deleted (or
 rather, their URLs).  It can be used to delay your service's reaction to events,
 for instance combined with Resque.
@@ -312,11 +324,16 @@
 
 It stores transient state in Redis and will emit `:entity_changed` events
 whenever an entity has changed. This event can usefully be fed into a dirty map,
 as in `Receiver::Filter` for instance.
 
+### Siphon
 
+[`Middleware::Siphon`](http://www.rubydoc.info/github/deliveroo/routemaster-drain/master/Routemaster/Middleware/Siphon) extracts
+payloads from the middleware chain, allowing them to be processed separately. This is useful for event topics where the update frequency is not well suited
+to frequent caching. For example, a location update event which you'd expect to receive every few seconds.
+
 ## Contributing
 
 1. Fork it ( http://github.com/deliveroo/routemaster-drain/fork )
 2. Create your feature branch (`git checkout -b my-new-feature`)
 3. Commit your changes (`git commit -am 'Add some feature'`)
@@ -325,5 +342,7 @@
 
 Do not bump version numbers on branches (a maintainer will do this when cutting
 a release); but please do describe your changes in the `CHANGELOG` (at the top,
 without a version number).
 
+If you have changed dependencies, you need to run `appraisal update` to make
+sure the various version specific gemfiles are updated.