"Arno Brinkman" <fbsupport@...> wrote:

>
> 2) fb_engine_info() has dbHandle so dispatcher can lookup provider.
> 3) fb_engine_info() has nodePath (string) which for example holds

servername(s) (and engine name?).

4) fb_engine_info() has no parameters, its Y-valve implementation just loads
all configured providers and call their fb_engine_info() methods. The engine
providers will return the required info, if they're active (loaded by active
attachments). Remote and services provider always return nothing. The
Y-valve then merges the results and returns them back to the services
provider that initiated the call.

The engine name is not necessary as we need information from all of them and
nobody but the Y-valve knows the configured engines. The host name is not
necessary as fb_engine_info() is intended to be called by the services
provider which is always executed on the server host (isc_service_attach()
contains a host name, so the Y-valve will pass the services call through the
wire). There's no need to mix local and remote engines as the request is
made via SAPI which is always connected to a particular server.

This is my proposal.

P.S. It's logical to restrict the server-wide info to SYSDBA only, but it's
up to the services manager to check that. It would mean that for an embedded
access fb_engine_info() could be called directly without proper
authentication, but any permissions make zero sense for the embedded access
anyway.


Dmitry