> All, including Dispatcher. Actually, it depends on what kind of
> information is requested.
> For example, configuration information belongs to Dispatcher only
> and other providers can't say anything useful.

I guess that providers still need the configuration, for example, to
decide how to authenticate the user - using target database or
security database. But I agree with you that providers should not need
part of the configuration about request routing.

> Who can answer about list of active databases I don't know.
> Probable, all active providers and dispatchers in stack.

I think that only engine providers can, but only about those that it
handles itself. Services provider has no attachments, so it can't (I
think gbak/gfix attachments should not be counted). Remote provider
handles only wire protocol. Dipatcher provider collects the
information from other providers.

> Yes, this is what we both are talking about. But I suggest to loop
> only through active providers while you are (AFAIU) going to use all
> providers known to dispatcher (mentioned in config?).

I have no problem about looping through the active providers only. But
I see no problem about looping through all providers too - inactive
providers will provide empty reply that will not influence the overall
result.

> And yes, dispatcher must be not as dumb as Jim would like it to
> be. It must keep some information (what it already does) and handle
> some requests itself (as it also already does - fb_start_mupltiple()
> for example).

Yes.

But now I have another question - why don't we move processing of the
Services API completely to the dispatcher and extend the subsystem
interface to execute database related service calls (like
backup/restore, gfix things, db properties, etc.)?

In this case all what we talk here will get its logic and beauty - all
database specific calls are handled by the engine providers, calls
that span multiple databases/providers - by the dispatcher. Initial
call comes into the dispatcher which a) knows what kind of call it is;
b) forwards the call to the needed endpoint; c) or processes the call
itself.

> >Arno and Jim suggest different thing. The idea is that Y-valve
> >delegates the info request to services provider, which has the list
> >of local engines and this services provider calls the same Y-valve
> >again specifying to which provider request should be forwarded.
> >After calling all specified engines, services provider processes
> >the responses and returns the reply back to the Y-valve, which in
> >turn returns it to the user.
>
> IMHO, this is a bad idea. We don't need another Dispatcher and
> especially hacks like this. DSQL in FB is made using the same
> technique and anybody can say anything good about it?..

Ok, then we are in the agreement here :)

Roman