> The services module in fact already does. isc_compile_request,
> isc_receive, etc... are called in the backup process.

I did not check the code, but are you 100% sure that you get a pointer
to the public isc_xxx calls from dispatcher and not that
implementation of these calls are simply statically linked in the
services provider implementation? If I remember correctly, the
subsystem API has no means to pass the function pointer of another
provider, does it?

Consider the situation when we have engine8 and engine11 providers and
single services provider (a bit nonsense, but good for this example).
How could the callback work, to which provider would dispatcher
redirect the request - engine8 or engine11? The configuration should
somehow specify that callback from services8 should go to engine8 and
from services11 to engine11... I have not seen such thing in the
Vulcan so far.

> The dispather is a provider when we call a provider a module that
> inherits from the subsystem.

Yes, this terminology is ok for me.

> > Sure, we can't do anything without this method. But simply adding it
> > to the subsystem won't solve the issue how to collect information.
> > Until now dispatcher was a stupid router that mapped handles and
> > forwarded requests according to the configuration. But now we
> > have to add some logic.
>
> Indeed the dispatcher will get the logic to combined the calls
> (which is pretty simple) from the defined providers or only from the
> first one that succeeds depending on what we decide.
> ...
> If we decide that only the first one that succeeds will be valid it
> doesn't have to handle the return-values itself. When we decide to
> concatenate the results it's so easy as removing the last byte
> (isc_info_end) and concatenate the next valid call. And at the end
> just add isc_info_end. I've also seen some kind of logic in the
> dispatcher by the dsqlSqlInfo method.

For me that would be acceptable (and probably also the most correct)
solution. But then we should stop calling Y-valve a dispatcher but
rather a provider that is able to redirect calls to other providers
according to some configuration if it decides so. Dispatcher somehow
bears the karma of a simple/stupid router. :)

> It would be nice if Jim will react in this discussion, but
> unfortunately i'm afraid he doesn't :(

It seems that we are in agreement about the necessary changes to the
concept. So if neither Jim nor Dmitry/Vlad/Alex question this approach
in a reasonable time, we consider it as accepted :)

Roman