> There is nothing wrong with a provider making calls back into the
> Y-valve through the proper, documented API provide that honors the
> "opaqueness" of handles. So both you and Roman are correct -- calls
> go only down the chain, but the dispatch modules can appear in the
> chain more than once. I trust that everyone understands that an
> infinite recursion isn't going to work very well.

Hmm... things are getting interesting. Do you mean that the same
instance of a dispatcher can appear multiple times in the chain or you
mean different instances? It looks like we are talking about the same
instance.

> Just a few words of advice. A dumber dispatch module is better than
> a smart one. Having it poll and aggregate subsystems is about as
> smart as it ought to get.

Frankly speaking, I like this kind smartness more than having to deal
with the recursion by inventing some smart mechanism to prevent
dispatcher calling a provider from which the callback originated
(either on API or on configuration level) - things seem to be less
complicated for an average mind like mine.

So personally now I vote to add a bit logic to Y-valve to poll
subsystems and aggregate the response and to abstain from callbacks to
the dispatcher as long as possible. Maybe after the sleep I will
change my mind :)

Roman