Subject Re: [Firebird-Architect] Vulcan services part II
Author Arno Brinkman

> 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.

That's almost the same as proposal 3 :-)
Except that you walk through the active providers and give no nodePath.
I added the nodePath so we could support going through the remote in the future, but this was certainly not for now.
With your proposal we will never be able to support the fb_engine_info() by remote, not that i see this a big problem.

> 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.

Same goes already for the current fb_shutdown_connections(), this doesn't require authentication too.

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: