Subject | Re: [Firebird-Architect] Vulcan services part II |
---|---|
Author | Arno Brinkman |
Post date | 2006-05-11T07:16:51Z |
Hi,
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.
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info
Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info
> 4) fb_engine_info() has no parameters, its Y-valve implementation just loadsThat's almost the same as proposal 3 :-)
> 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.
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'sSame goes already for the current fb_shutdown_connections(), this doesn't require authentication too.
> 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.
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info
Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info