Thanks.. I think that for the level of usage I envision, the flexiblity of [chain] (and relative maturity) solves the problem, even though [pipeline] may in a larger sense be more appropriate for my use case.
My usecase, processing data, seems to fit into exactly what [pipeline] does. In fact, I call it a pipeline. However, in my own implementation, a specific valve may shut off execution of future valves, similar to how a command in the [chain] may not pass on control to the next element in the chain. So, from that standpoint, [chain] is more appropriate. I'm looking forward to using [chain] and see what I can help out on. I'll be using it triggered from a Quartz process, so I'll be looking at agility a bit, but it seems like my needs are even simpler then that: Put context in at one end. Get context out at other end. Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
