Hi,

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

<database *>
filename $0
provider remote engine11 engine8
</database>

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

My proposal is to add this to the master.conf

<engines>
provider engine11 engine8
</engines>

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.

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database development 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
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Firebird and Interbase users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info