> Currently in vulcan the services don't provide information about the
> number of attachments, databases and attached db-names. This code is
> disabled because the way it was implemented it breaks the layering.
>
> To enable this service function again i propose to add a function
> called fb_engine_info() to the engine. This function should be
> extensible for future features, so i propose to use info items (same
> as isc_database_info). Some new info items needs to be declared for
> fb_engine_info() inside ibase.h.
>
> The function needs also to be added to the subsystem (and by default
> does nothing?). Engine8 will override it and call the function in
> jrd.
>
> We could have multiple engines, so we need to walk through all known
> providers and subsystems. For every subsystem from the provider the
> fb_engine_info() function is called. As far as i understand the
> Dispatcher it the place to handle this.
>
> I see some problems with walking through all providers:
> What if an info_item isn't supported by engine-old, but it is by
> engine-new. We can't ask information for a specific engine.
>
> Ideas, suggestions, comments?

I think we have two problems here.

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.

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.

Problem 2: Collect the information from providers. The solution to
your problem I think is to design the info call in such a way that all
unknown constants are ignored. This will be enough to let the
implementation described in previous case to collect necessary
information.

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

Roman