|Subject||Re: Vulcan services engine info. was (engine information (nr. of attachments, da|
> All, including Dispatcher. Actually, it depends on what kind ofI guess that providers still need the configuration, for example, to
> information is requested.
> For example, configuration information belongs to Dispatcher only
> and other providers can't say anything useful.
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.I think that only engine providers can, but only about those that it
> Probable, all active providers and dispatchers in stack.
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 loopI have no problem about looping through the active providers only. But
> only through active providers while you are (AFAIU) going to use all
> providers known to dispatcher (mentioned in config?).
I see no problem about looping through all providers too - inactive
providers will provide empty reply that will not influence the overall
> And yes, dispatcher must be not as dumb as Jim would like it toYes.
> 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).
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
> >Arno and Jim suggest different thing. The idea is that Y-valveOk, then we are in the agreement here :)
> >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?..