> The services module can call the in the Y-valve (Dispatcher) to ask
> for engine information and the dispatcher will walk
> through all known providers and his subsystems to ask for
> information. This way the services module is able to handle
> return the needed information.

It can't. Check all pictures from the Vulcan Architecture description.
The call goes from upper layer to lower layer and response goes from
lower layer to the upper layer:

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=vul_architecture

So, provider cannot call its dispatcher, otherwise the whole Vulcan
concept will be broken. We don't want this, do we?

> > Also traversing all providers cannot be done by another provider,
> > but a component above those. So, I still believe that additional
> > API is needed to handle the "server-wide" requests.
>
> The dispatcher can do this.

Only when you declare dispatcher to be some kind of provider that can
handle some requests and forward others. But we need Jim to discuss
whether this is acceptable in his architecture or not.

> > As to my post about XML-RPC... Some time ago, if I remember
> > correctly,
> > Jim wanted to make all services available via the separate process
> > that would call either gbak or gfix (or any other command) and
> > translate their responses back in XML.
>
> IMO you'll remain with the problem how to get the information and
> that's why proposal to add fb_engine_info() to the
> subsystem.

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.

> The Y-valve methods inherited also from the sub-system and those
> handles (dbHandle, svcHandle, reqHandle, blobHandle,
> ..) are internally mapped to the calling provider handles. For the
> engine-info call we don't have a (engine-) handle and
> i doubt if we need it.

Yes, but so far it had no true logic inside. Now dispatcher has to
look into the contents of the service call (SPB and SRB) and do some
additional processing (call all active providers instead of one and at
least sum all responses) and only then return response to the client.

And this is the place where we need Jim as an original creator of this
architecture - he has to tell us whether such extension is acceptable
or not, and if not - suggest a direction in which we have to dig.

Roman