Please sign in to comment.
bug fixes, docs, ready for point release.
- Loading branch information...
Showing with 189 additions and 54 deletions.
|@@ -0,0 +1,19 @@|
|+Copyright (c) 2012 Corey Jewett|
|+Permission is hereby granted, free of charge, to any person obtaining a copy|
|+of this software and associated documentation files (the "Software"), to deal|
|+in the Software without restriction, including without limitation the rights|
|+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell|
|+copies of the Software, and to permit persons to whom the Software is|
|+furnished to do so, subject to the following conditions:|
|+The above copyright notice and this permission notice shall be included in|
|+all copies or substantial portions of the Software.|
|+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR|
|+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,|
|+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE|
|+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER|
|+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,|
|+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN|
|@@ -1,4 +1,16 @@|
|-Easily create and manage daisychains of async queues.|
|+Easily create and manage a chain of async queues. Each queue worker may emit an error or a single memo object to it's callback. just like async#push, an error is handed to the callback given. In the case of a memo, it is forwarded to the next queue. When the last queue finishes the resulting memo is passed to the originating callback.|
|+ var daisychain = require("async-daisychain");|
|+ // see test/test.js for a couple examples|
|+When an error is passed to the callback the second argument is the memo from the last successful worker and the third argument passed to the callback is the queue_id for the failed queue. These arguments, plus a callback, may be passed to #retry to reinvoke the failed queue and remaining queues on the memo. In a sense, this is reminiscent of ruby's *retry* statement and was inspired by it. This is particularly handy where a worker might fail due to intermittent IO issues. In most cases it also would make sense to delay for some interval before retrying, but this is not built in currently.|
|+Functionally, this is similar to an async *queue* whose worker spawns a *waterfall* for each task. That strategy is actually more flexible as it is not limited to a single memo. On the upside, the added complexity herein provides the retry mechanics and also has opportunity to be improved by having mixed concurrency and also an intellgent backpressure system that has visibility into the whole system, not just it's head.|