Subject Re: [Firebird-Architect] Re: Engine information (nr. of attachments, databases, db-name-info) for vulcan
Author Arno Brinkman

> Problem 1: Obtain a server-wide information. I guess the idea of
> providers and configuration in Vulcan is to determine the single
> entity that will process the request and I'm not sure that we want to
> extend this mechanism to provide also possibility to redirect requests
> to multiple providers.

Yes, the first provider that can handle the call without errors is used.
For createDatabase this also depends on the databasename or alias:

<database eng8#*>
filename $1
provider engine8

<database *>
filename $0
provider remote engine11 engine8

> What we need is another mechanism that will provide server-wide
> information (or thinking further, will do also server-wide tasks, like
> configuration file management). If I remember correctly, that was
> planned for a new XML-enabled "Services API". As we have to fix the
> Services API in Vulcan anyway, we can also extend it with the service
> to provide the number of attachments, attached db names, etc.
> Implementation of this service can loop through providers, collect
> some provider-local information, process it and then provide single
> reply to client.

The question is which providers and what should the current isc_info_svc_svr_db_info return. Only
information from the first provider that can process the call or combine the info from all providers

My proposal is to add this to the master.conf

provider engine11 engine8

That will then be the list used by the dispatcher.

> Problem 2: Collect the information from providers.
> If we want to return the reply from different providers to the client,
> we have to exetend this "server-wide" processor to walk through all
> providers, call this fb_engine_info and concatenate the responses in a
> single response separating replies from each provider with two
> additional flags, something like isc_info_provider_start and
> isc_info_provider_end. This will allow clients to correctly process
> the information returned by multiple providers.
> Something like this
> isc_info_start
> isc_info_provider_start
> ...
> isc_info_provider_end
> isc_info_provider_start
> ...
> isc_info_provider_end
> isc_info_end

Yes, something like that. Probably we should also add the provider-name in it.
This means some more "intelligence" should go in the dispatcher, but this is also there for
serviceAttach and createDatabase.

Arno Brinkman

General database development support:

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

Support list for Firebird and Interbase users :

Nederlandse firebird nieuwsgroep :